[PATCH RESEND] x86/cpu/intel: replace deprecated strcpy with strscpy

[PATCH RESEND] x86/cpu/intel: replace deprecated strcpy with strscpy

[Ruben Wauters]

strcpy is deprecated due to lack of bounds checking.
This patch replaces strcpy with strscpy, the recommended alternative for
null terminated strings, to follow best practices.

Signed-off-by: Ruben Wauters <rubenru09@aol.com>
---
This patch was reviewed by H. Peter Anvin and (by my understanding)
was deemed ok to apply. However this patch has not been applied after 2
weeks, so I am resending it. I have not added a Reviewed-by tag as H.
Peter Anvin did not do so.

I also wanted to note that while immediately this may not have any
effect, any addition or changes to the strings above may possibly
overflow the fixed buffer of 64, and the use of strscpy instead of
strcpy will help prevent any buffer overflows by copying a max amount of
bytes. I do also recognise however that the strings above are unlikely
to be added to, as (by my understanding) they'd require intel to release
a CPU where the x86_model_id would not be detectable.

I still believe that while the above scenerio may not come to pass, the
replacement of a deprecated API with the preferred alternative is good
practice and should be done.
---
 arch/x86/kernel/cpu/intel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 584dd55bf739..b49bba30434d 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -607,7 +607,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 		}
 
 		if (p)
-			strcpy(c->x86_model_id, p);
+			strscpy(c->x86_model_id, p);
 	}
 #endif
 
-- 
2.48.1

Re: [PATCH RESEND] x86/cpu/intel: replace deprecated strcpy with strscpy

[Ruben Wauters]

On Tue, 2025-05-20 at 14:26 +0100, Ruben Wauters wrote:
> strcpy is deprecated due to lack of bounds checking.
> This patch replaces strcpy with strscpy, the recommended alternative
> for
> null terminated strings, to follow best practices.
> 
> Signed-off-by: Ruben Wauters <rubenru09@aol.com>
> ---
> This patch was reviewed by H. Peter Anvin and (by my understanding)
> was deemed ok to apply. However this patch has not been applied after
> 2
> weeks, so I am resending it. I have not added a Reviewed-by tag as H.
> Peter Anvin did not do so.
> 
> I also wanted to note that while immediately this may not have any
> effect, any addition or changes to the strings above may possibly
> overflow the fixed buffer of 64, and the use of strscpy instead of
> strcpy will help prevent any buffer overflows by copying a max amount
> of
> bytes. I do also recognise however that the strings above are
> unlikely
> to be added to, as (by my understanding) they'd require intel to
> release
> a CPU where the x86_model_id would not be detectable.
> 
> I still believe that while the above scenerio may not come to pass,
> the
> replacement of a deprecated API with the preferred alternative is
> good
> practice and should be done.
> ---
>  arch/x86/kernel/cpu/intel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/intel.c
> b/arch/x86/kernel/cpu/intel.c
> index 584dd55bf739..b49bba30434d 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -607,7 +607,7 @@ static void init_intel(struct cpuinfo_x86 *c)
>  		}
>  
>  		if (p)
> -			strcpy(c->x86_model_id, p);
> +			strscpy(c->x86_model_id, p);
>  	}
>  #endif
>  

Hello
I was wondering if there was any chance this patch could be applied? is
there something I need to do to change it so it's fine? is there
someone else I need to send it to so they can review it?

I don't want to keep sending and asking about an unwanted patch so if
this isn't wanted please let me know and I'll move on.

Thank you

Ruben Wauters

Re: [PATCH RESEND] x86/cpu/intel: replace deprecated strcpy with strscpy

[Borislav Petkov]

Hi,

On Wed, May 28, 2025 at 04:34:51PM +0100, Ruben Wauters wrote:
> I was wondering if there was any chance this patch could be applied? is
> there something I need to do to change it so it's fine? is there
> someone else I need to send it to so they can review it?
> 
> I don't want to keep sending and asking about an unwanted patch so if
> this isn't wanted please let me know and I'll move on.

the tip tree is open for new code after the merge window is over.

From: Documentation/process/maintainer-tip.rst

Merge window
^^^^^^^^^^^^

Please do not expect large patch series to be handled during the merge
window or even during the week before.  Such patches should be submitted in
mergeable state *at* *least* a week before the merge window opens.
Exceptions are made for bug fixes and *sometimes* for small standalone
drivers for new hardware or minimally invasive patches for hardware
enablement.

During the merge window, the maintainers instead focus on following the
upstream changes, fixing merge window fallout, collecting bug fixes, and
allowing themselves a breath. Please respect that.

The release candidate -rc1 is the starting point for new patches to be
applied which are targeted for the next merge window."

IOW, be patient please. You're not the only one with a patch...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

[PATCH RESEND] x86/cpu/intel: replace deprecated strcpy with strscpy

[Ruben Wauters]

strcpy is deprecated due to lack of bounds checking.
This patch replaces strcpy with strscpy, the recommended alternative for
null terminated strings, to follow best practices.

Signed-off-by: Ruben Wauters <rubenru09@aol.com>
---
This patch was reviewed by H. Peter Anvin and (by my understanding)
was deemed ok to apply. I have not added a Reviewed-by tag as H.
Peter Anvin did not do so.

The last time I resent this patch was during the merge window so it
understandably did not get applied or further reviewed.
I have resent it again as the merge window has now closed, hopefully
so it can be further reviewed and applied
---
 arch/x86/kernel/cpu/intel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 584dd55bf739..b49bba30434d 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -607,7 +607,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 		}
 
 		if (p)
-			strcpy(c->x86_model_id, p);
+			strscpy(c->x86_model_id, p);
 	}
 #endif
 
-- 
2.48.1

Re: [PATCH RESEND] x86/cpu/intel: replace deprecated strcpy with strscpy

[Borislav Petkov]

On Mon, Jun 30, 2025 at 03:29:30PM +0100, Ruben Wauters wrote:
> strcpy is deprecated due to lack of bounds checking.
> This patch replaces strcpy with strscpy, the recommended alternative for
> null terminated strings, to follow best practices.
> 
> Signed-off-by: Ruben Wauters <rubenru09@aol.com>
> ---
> This patch was reviewed by H. Peter Anvin and (by my understanding)
> was deemed ok to apply. I have not added a Reviewed-by tag as H.
> Peter Anvin did not do so.
> 
> The last time I resent this patch was during the merge window so it
> understandably did not get applied or further reviewed.
> I have resent it again as the merge window has now closed, hopefully
> so it can be further reviewed and applied
> ---
>  arch/x86/kernel/cpu/intel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index 584dd55bf739..b49bba30434d 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -607,7 +607,7 @@ static void init_intel(struct cpuinfo_x86 *c)
>  		}
>  
>  		if (p)
> -			strcpy(c->x86_model_id, p);
> +			strscpy(c->x86_model_id, p);
>  	}
>  #endif

"strcpy()
--------
strcpy() performs no bounds checking on the destination buffer. This
could result in linear overflows beyond the end of the buffer, leading to
all kinds of misbehaviors. While `CONFIG_FORTIFY_SOURCE=y` and various
compiler flags help reduce the risk of using this function, there is
no good reason to add new uses of this function."

From: Documentation/process/deprecated.rst

Note the "new uses of this function".

This is old code, there are no problems with it so unless I'm missing
something, if it ain't broke, there's no need to fix it.

But I'm *sure* you'll find something else in the kernel which is really broken
and you could send a fix then...

:-)

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette