Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp8747023imu; Thu, 15 Nov 2018 17:12:01 -0800 (PST) X-Google-Smtp-Source: AJdET5eQXvV64bqsGsaFBptcjRRAOSg0qs/sEZ2YQwDpxPSocqgygxFR5X9WIYb/asgLYrH4EvcD X-Received: by 2002:a62:3346:: with SMTP id z67-v6mr9068996pfz.112.1542330720962; Thu, 15 Nov 2018 17:12:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542330720; cv=none; d=google.com; s=arc-20160816; b=0wU2sZXrCwgWeoPufzBXjR1GdkzYRrK1eleAWCad6HwmDwDrwqJ6x6UDg+gBC7QppC mzCw+Mz9sfihVaYgFPIpuLwG3tfnAtSicarV7qwLF/bXMn0CoymRb16tvV7uQuZ5NVV+ iLAeIBlQ3O6y5/ITDexXVpXyDBoot7l8b6ajqCrl2DQ2VpnygsjmG3qfhFfWcKKSOtkd g+M7wp+adgfvt0j8uDjDdCo0VGjUD8nthCMZYb+hwMc7QuLNOjld+xXcwA+kVHH9OJEr 4gbt5sfGMxNS2RCyWUD9uLLfnm3PBAP3S0kgE/he1ov6bJV22olKVp3SIrybuXZ3ykZ3 VE0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=uUdYXNvl55K6wbXFRulAc5o6dhQhJefkXW0PQayrit4=; b=kX2xzXHBM/tupax3HnPJ+iH/3Ohs8y557zvTD0fqi4Vrlt92mRq+cnS5eg//hq48hq L9WkNNek8ADH40rpjdzZAH4rpr+XpeV2JuS3qHSASWQTVRmb4Fq5cnsxkQ5L632ALPXz 9rv5WagO1g9gS+QhW08Wmr7J1M5gAtl8RtKPZbms/0NrsgAROTLedtF39EnQjSS2SBJ/ /AntM3Fu7bLV3/cIuIJCwUgzrlspRBuHviZO8V+IlnG0w7tuzZAhrOWUw9dqa+PIMGRG roi7jM/kMejieZSOgVTdoAjqzWxJ+iyssy9RPpLkve/K67R3DnjVyOwU/VmHk/xPNMKg SYYw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=cIwchEGE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h31si4570752pgl.482.2018.11.15.17.11.46; Thu, 15 Nov 2018 17:12:00 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=cIwchEGE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389094AbeKPLVP (ORCPT + 99 others); Fri, 16 Nov 2018 06:21:15 -0500 Received: from mail-yb1-f193.google.com ([209.85.219.193]:46892 "EHLO mail-yb1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726518AbeKPLVP (ORCPT ); Fri, 16 Nov 2018 06:21:15 -0500 Received: by mail-yb1-f193.google.com with SMTP id i17-v6so9140064ybp.13 for ; Thu, 15 Nov 2018 17:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uUdYXNvl55K6wbXFRulAc5o6dhQhJefkXW0PQayrit4=; b=cIwchEGEnUsMqjXIxz0LS+acI+fQ0jV+ZASQI3BU/8MlV31pEG4dGbD25qwSOBYltP eT7GWey09+0CIOe+/xxrSMUZX6L2wG1sVYngWfSIMRZgytmsjFm7JBHE3f1TChXu+aNi Eel0OKO18FSVj86k12JUjjp0eYVDxWnkJUV+s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uUdYXNvl55K6wbXFRulAc5o6dhQhJefkXW0PQayrit4=; b=pSeXUWZU94nrvjWwV4Z4ed6GK7o78R30UiyQsRkdWu/97c6Una7vvt9FbIkVD8/rRA D4B9L3whaInlYkVwlFG4sXkXoXaydXzOqOSzcL49bdLtDjX5PZ/qyR39Lqtd1PRFRTq8 nykc29Kx+canRQWdzpVnd32/6F7LtuQYhqy/qMC2t4H1OEmTmXBP/xCpB9B/D9DYlzzd zphmUbVcXDb6sHmh9/soZgEgptrlow5JhGzbE8RvOIYlaPmNgwPqwFt5ac87t4Drs8KR e7/51n7fJ7NNtcG4zbrPOugFSNIVI3goJjFhU30LboKnTnZCIHOjXr0yKeZAo/BKaAgb S45Q== X-Gm-Message-State: AGRZ1gKgqrzHufLdHfKMKlRg0R9LohtnkTpxYhtRYh/+kHl7VmMDPy1V /HwAS+/rg02z8El1cnVuFYmgaRWFIas= X-Received: by 2002:a25:5443:: with SMTP id i64-v6mr8884401ybb.287.1542330658719; Thu, 15 Nov 2018 17:10:58 -0800 (PST) Received: from mail-yw1-f53.google.com (mail-yw1-f53.google.com. [209.85.161.53]) by smtp.gmail.com with ESMTPSA id u130-v6sm7207100ywa.71.2018.11.15.17.10.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Nov 2018 17:10:57 -0800 (PST) Received: by mail-yw1-f53.google.com with SMTP id p18-v6so9436540ywg.12 for ; Thu, 15 Nov 2018 17:10:55 -0800 (PST) X-Received: by 2002:a0d:d302:: with SMTP id v2-v6mr8634737ywd.124.1542330655097; Thu, 15 Nov 2018 17:10:55 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:b906:0:0:0:0:0 with HTTP; Thu, 15 Nov 2018 17:10:53 -0800 (PST) In-Reply-To: References: <20181114131642.21425-1-dh.herrmann@gmail.com> From: Kees Cook Date: Thu, 15 Nov 2018 19:10:53 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] Revert "HID: uhid: use strlcpy() instead of strncpy()" To: David Herrmann Cc: Laura Abbott , "open list:HID CORE LAYER" , linux-kernel , Jiri Kosina , Benjamin Tissoires , Xiongfeng Wang Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 15, 2018 at 5:55 AM, David Herrmann wrote: > Hi > > On Thu, Nov 15, 2018 at 12:09 AM Kees Cook wrote: >> On Wed, Nov 14, 2018 at 9:40 AM, Laura Abbott wrote: > [...] >> > Can we switch to strscpy instead? This will quiet gcc and avoid the >> > issues with strlcpy. >> >> Yes please: it looks like these strings are expected to be NUL >> terminated, so strscpy() without the "- 1" and min() logic would be >> the correct solution here. > > "the correct solution"? To my knowledge the original code was correct > as well. Am I missing something? So, yes, no one should use strlcpy(): https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy And while I think nothing was technically wrong with the strncpy() usage in the original version, I think strncpy() should only be used for __nonstring cases: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings > >> If @hid is already zero, then this would >> just be: >> >> strscpy(hid->name, ev->u.create2.name, sizeof(hid->name)); >> strscpy(hid->phys, ev->u.create2.phys, sizeof(hid->phys)); >> strscpy(hid->uniq, ev->u.create2.uniq, sizeof(hid->uniq)); >> >> If they are NOT NUL terminated, then keep using strncpy() but mark the >> fields in the struct with the __nonstring attribute. > > They are supposed to be NUL terminated, but for compatibility reasons > we allow them to be not. So I don't think your proposal is safe. I was originally thinking only about the the hid->* strings, so I was confused by this answer (they appear to always be NUL-terminated). Then I thought you meant that ev->u.create2.* strings may not be terminated, but I stayed confused. :) The original code was: len = min(sizeof(hid->name), sizeof(ev->u.create2.name)) - 1; strncpy(hid->name, ev->u.create2.name, len); If sizeof(hid->name) is smaller than sizeof(ev->u.create2.name), it made sure than hid->name kept a trailing NUL. If sizeof(ev->u.create2.name) is smaller than sizeof(hid->name), it made sure than the last byte of ev->u.create2.name was ignored, and by definition, hid->name would be NUL-terminated. So you're converting from a potentially unterminated string into a terminated string... (ev->u.create2.name maybe needs to be marked __nonstring?) The most you can write is sizeof(dest) - 1 but you must not read more than sizeof(source). So I see that if the destination is smaller than the source, you cannot represent these conditions correctly to strscpy(). (And, I would argue, you can't with strncpy() either.) However, they're all exactly the same size, so none of this matters, and I think strscpy() would be the most sensible. And maybe you could enforce the size checking: BUILD_BUG_ON(sizeof(hid->name) != sizeof(ev->u.create2.name)); strscpy(hid->name, ev->u.create2.name, sizeof(hid->name)); etc... -- Kees Cook