Linux driver-core infrastructure
 help / color / mirror / Atom feed
* [PATCH next] driver core: Replace strcpy() with memcpy()
@ 2026-06-06 20:25 david.laight.linux
  2026-06-09 14:08 ` Danilo Krummrich
  0 siblings, 1 reply; 4+ messages in thread
From: david.laight.linux @ 2026-06-06 20:25 UTC (permalink / raw)
  To: Kees Cook, linux-hardening, Arnd Bergmann, driver-core,
	linux-kernel
  Cc: Danilo Krummrich, Greg Kroah-Hartman, Rafael J. Wysocki,
	David Laight

From: David Laight <david.laight.linux@gmail.com>

The length of the string is calculated in order to allocate the correct
sized memory block, use the same length to copy in the string.

Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
This is one of a group of patches that remove potentially unbounded
strcpy() calls.

They are mostly replaced by strscpy() or, when strlen() has just been
called, with memcpy() (usually including the '\0').

Calls with copy string literals into arrays are left unchanged.
They are safe and easily detected as such.

The changes were made by getting the compiler to detect the calls and
then fixing the code by hand.

Note that all the changes are only compile tested.

Some Makefiles were changed to allow files to contain strcpy().
As well as 'difficult to fix' files, this included 'show' functions
as they really need to use sysfs_emit() or seq_printf().

All the patches are being sent individually to avoid very long cc lists.
Apologies for the terse commit messages and likely unexpected tags.
(There are about 100 patches in total.)

 drivers/base/platform.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

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);
 
-	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);
 		pa->pdev.name = pa->name;
 		pa->pdev.id = id;
 		device_initialize(&pa->pdev.dev);
-- 
2.39.5


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH next] driver core: Replace strcpy() with memcpy()
  2026-06-06 20:25 [PATCH next] driver core: Replace strcpy() with memcpy() david.laight.linux
@ 2026-06-09 14:08 ` Danilo Krummrich
  2026-06-09 15:22   ` David Laight
  0 siblings, 1 reply; 4+ messages in thread
From: Danilo Krummrich @ 2026-06-09 14:08 UTC (permalink / raw)
  To: david.laight.linux
  Cc: Kees Cook, linux-hardening, Arnd Bergmann, driver-core,
	linux-kernel, Greg Kroah-Hartman, Rafael J. Wysocki

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.

>  
> -	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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH next] driver core: Replace strcpy() with memcpy()
  2026-06-09 14:08 ` Danilo Krummrich
@ 2026-06-09 15:22   ` David Laight
  2026-06-09 22:49     ` Danilo Krummrich
  0 siblings, 1 reply; 4+ messages in thread
From: David Laight @ 2026-06-09 15:22 UTC (permalink / raw)
  To: Danilo Krummrich
  Cc: Kees Cook, linux-hardening, Arnd Bergmann, driver-core,
	linux-kernel, Greg Kroah-Hartman, Rafael J. Wysocki

On Tue, 09 Jun 2026 16:08:55 +0200
"Danilo Krummrich" <dakr@kernel.org> 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.
There is also the issue that, in principle (but probably not in practise),
the input string might change between the strlen() and the copy.
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.
It probably wouldn't eliminate a second strlen(name) either.

I'm not trying to remove strlen(), just strcpy().

But not just changing them all the strscpy().

	David

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH next] driver core: Replace strcpy() with memcpy()
  2026-06-09 15:22   ` David Laight
@ 2026-06-09 22:49     ` Danilo Krummrich
  0 siblings, 0 replies; 4+ messages in thread
From: Danilo Krummrich @ 2026-06-09 22:49 UTC (permalink / raw)
  To: David Laight
  Cc: Kees Cook, linux-hardening, Arnd Bergmann, driver-core,
	linux-kernel, Greg Kroah-Hartman, Rafael J. Wysocki

On Tue Jun 9, 2026 at 5:22 PM CEST, David Laight wrote:
> On Tue, 09 Jun 2026 16:08:55 +0200
> "Danilo Krummrich" <dakr@kernel.org> 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.

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?

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-06-09 22:49 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-06 20:25 [PATCH next] driver core: Replace strcpy() with memcpy() david.laight.linux
2026-06-09 14:08 ` Danilo Krummrich
2026-06-09 15:22   ` David Laight
2026-06-09 22:49     ` Danilo Krummrich

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox