From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8DA5C3DEAC7 for ; Wed, 10 Jun 2026 09:25:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781083557; cv=none; b=qUd2YIV5geVkgmQi6Q45JSrnPlXkn7loQ/32ZUtcQ6dr5/GDaL23gCwJ5LkLmOB7Dar/ikxyj/TyMK8AgxfB8H56Oe1tqYdMVielT5LJpbC2EUoV7k8FwgWFFS25c683Ef2cxn2AlRjaddj5MiesznzWZIJRTgfWyMe7lqTM0/A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781083557; c=relaxed/simple; bh=1vXzvFUOfc9XwAC8q5N/sOdpK4L0M5KL0CA4o+35Qi8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Jfy9NqHgXXGoTjAfTMGCexrJy/Rn1xP8Qoo2bk4BsceDsp6vKEXt3N2j+b7e9Um4WPGc/V6BWf1vSYw1J/J+UzysqMSnu0uZzTGFxxkLxFDMlxwRpEY2kQg/Ry72VeyFbUkWNoo1PtJTRsbWV+ooGwpW6UyCbukEuyT3jjwP1A0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=j/VZGEtD; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="j/VZGEtD" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-490be29c1c5so82797835e9.2 for ; Wed, 10 Jun 2026 02:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781083552; x=1781688352; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=6m47JVDwNRIxN+tYRIL+SQbEWAt5ykAINiL7bz4tPVs=; b=j/VZGEtDSOp5KXC8Vx6xZP6ZnCyTe3E08JQTSrdpJ4g6+mjXsE6+fiRTV6ii9aM2fN qqedzMniD0DbLr1xbQ0CJGP0INIAaTMAd7hMFApSgiMKKc+qIDzh69hFYvCg8kWE7BTJ sWovgSU/ZK6840Fn0R9LN6pxh0RTcZvj7JfDF0j6MKKWLvj7DLxK1ihbw2VZM35CGOgV 3HnXrxlZggfn6n1AWubBbktOgYQpAK6qsp9Vifa5ICSnAqVyxoI4ZvEK+nhaDQiXA/Nd kM7wNzgNfwq2CbQfJdevPEdD+kXtb/0vs3Km3L0yvgBXKyHsO0HvijpTCtHRklINGDjK QVyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781083552; x=1781688352; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=6m47JVDwNRIxN+tYRIL+SQbEWAt5ykAINiL7bz4tPVs=; b=gNI4SmakMO5KRDZKCCTi3DE3Zgg15aWHJwQ4HtISyejOGmVBzITsbnKnNFzczavCoH 3p2a777Ywl9ximo5o9rUDmnlq0nuJk0WNFXDueRpaqolCBn23od9Dk2fxHV/vNhb8C1S K1ko20BdoLcKWhxK4ngn30AQXmckL3DDCJJZ+y1B5FOKfsTGGbSECTaAYmzLD4bNBiML en0qmw8zxB4wrXArOOm+tLGHUqQur9J5zhyGCkMDGl/T2n/xPx5s/De6KsNC1fqM+5SA Y24wvfgY02BP2zWAf4etWK4Mb4MPUZydf7djcL0bON36vCHzXCya9cToUnv948SLyKvq 6LqQ== X-Forwarded-Encrypted: i=1; AFNElJ/l0cB23boax1U56tqeAwJCfuE5knGYADeotN3P1m+/lzAZNyDXz7saeoDhyVZOQxma+85TJ4MpS31bpD8=@vger.kernel.org X-Gm-Message-State: AOJu0YypHitPdMb+BtaFH54b0AWl+0gQZJBslAsjRqFY7YtpDtOe5jt/ oh4PPRNDzVgkIEJRaXmUk1u8j0etQAVjqQ/SB6Gbgnn+uv3sC5bIsQqq X-Gm-Gg: Acq92OGEXwY2qY72W+gOWzKC9n/99IZdnlwvskeuBf2q+HeyuJhvKaFY+Z7fd8RcfXH GTP4YO/2exJ5HQJuRlUX3xLHVvG9qNmmIydzyy8dh/E5xc3xdr2SJTddztMzcLsgGYQL1FMP7J2 B2b+/55GMRTPMgbnCBs0B6xYPL0yuB3iqontZsC70qIbRxw+jcsOUwnxQsDbyJGRXGVuxg3FzN5 a1kpCjSY6qgula02NRT5wt/k35cGCC9N08iolCke327wDA/A/vz/Czg2gWb01xtU9xpxBGl+P1N p9/LQwUof9ldTkpHvTjox/CM/AuyAcgJ1E5Hjz09dGf2bv/w2ZCCEf0LEVhp8b4KOCGv2qVzs6Z ykNyqtZ2Zcg7EHFa6y/M6IsdhxXHeccmcgtg0WZ4iHc/tRmR5gXtbgWm1JQTQOu5HsjT/ZEnnqX DoTWoabnE1X0+z4IGoL8sTV5TUFxq1msutTIAcp7Y7Ptb4OBNIQa3x2ZCWXYJbiwmwXll643c= X-Received: by 2002:a05:600c:8183:b0:488:a882:c7 with SMTP id 5b1f17b1804b1-490c25c6625mr340667165e9.25.1781083551620; Wed, 10 Jun 2026 02:25:51 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490bc39eb04sm552542965e9.6.2026.06.10.02.25.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2026 02:25:51 -0700 (PDT) Date: Wed, 10 Jun 2026 10:25:50 +0100 From: David Laight To: "Danilo Krummrich" Cc: "Kees Cook" , , "Arnd Bergmann" , , , "Greg Kroah-Hartman" , "Rafael J. Wysocki" Subject: Re: [PATCH next] driver core: Replace strcpy() with memcpy() Message-ID: <20260610102550.723c4cc1@pumpkin> In-Reply-To: References: <20260606202633.5018-1-david.laight.linux@gmail.com> <20260609162258.5228eda2@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 10 Jun 2026 00:49:10 +0200 "Danilo Krummrich" wrote: > On Tue Jun 9, 2026 at 5:22 PM CEST, David Laight wrote: > > On Tue, 09 Jun 2026 16:08:55 +0200 > > "Danilo Krummrich" wrote: > > > >> On Sat Jun 6, 2026 at 10:25 PM CEST, david.laight.linux wrote: > >> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c > >> > index 75b4698d0e58..63fdfffe1a8c 100644 > >> > --- a/drivers/base/platform.c > >> > +++ b/drivers/base/platform.c > >> > @@ -617,10 +617,11 @@ static void platform_device_release(struct device *dev) > >> > struct platform_device *platform_device_alloc(const char *name, int id) > >> > { > >> > struct platform_object *pa; > >> > + size_t len = strlen(name); > >> > >> This could be strlen(name) + 1 right away, which would also avoid the memcpy() > >> to implicitly rely on kzalloc() zeroing the memory, where strcpy() was > >> self-contained before. > > > > I tried not to do that 'optimisation'. > > Here the kzalloc() is almost certainly needed for other reasons. > > This is true, it is needed for other reasons anyway. My point is that currently > it is self-contained and it doesn't matter if the preconditions ever change, so > I'd rather we have strlen(name) + 1 right away. > > > There is also the issue that, in principle (but probably not in practise), > > the input string might change between the strlen() and the copy. > > This is not a concern for this function, but let's assume it was, then your > proposed patch wouldn't prevent anything bad either. > > For instance, if the string would change to be shorter than what strlen() > measured, the memcpy() becomes invalid either way. Becoming shorter doesn't matter. The problem is if is becomes longer (in some fixed length buffer). Then the copied string isn't terminated. This does happen for updates of current->comm so can be a real problem. > > Also, in that case the strcpy() would be more robust and vice versa with a > longer one. But again, this is not a realistic scenario anyway. > > > So it is probably best practise to not rely on the '\0' still being > > there when the copy is done. > > > >> > >> > > >> > - pa = kzalloc(sizeof(*pa) + strlen(name) + 1, GFP_KERNEL); > >> > + pa = kzalloc(sizeof(*pa) + len + 1, GFP_KERNEL); > >> > if (pa) { > >> > - strcpy(pa->name, name); > >> > + memcpy(pa->name, name, len); > >> > >> But in general, what's the improvement? strlen() still operates on a potentially > >> unbounded string? > >> > >> It removes the redundant strlen() calculation that is implied by the current > >> code, though this may be eliminated by CSE optimization. > > > > CSE won't eliminate it. > > Ok, but in the context of platform_device_alloc() not a huge benefit either. > > Is there any other reason for this change? Am I missing something? I'm sure there is an overall plan to remove all calls to strcpy() and strcat() because of their potential to overrun the destination buffer. -- David