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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7a83ac38b5f2c9d7ec08c04a63299d2eeaa832fe.camel@aol.com>
Date: Wed, 28 May 2025 16:34:51 +0100
From: Ruben Wauters <rubenru09@....com>
To: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, 
 Borislav Petkov
	 <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org
Cc: "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND] x86/cpu/intel: replace deprecated strcpy with
 strscpy

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