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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <758195078eee66ce97c05091004bca9d5c3b6cd9.camel@aol.com>
Date: Wed, 07 May 2025 21:30:07 +0100
From: Ruben Wauters <rubenru09@....com>
To: "H. Peter Anvin" <hpa@...or.com>, 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: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/cpu/intel: replace deprecated strcpy with strscpy

On Wed, 2025-05-07 at 13:14 -0700, H. Peter Anvin wrote:
> On May 7, 2025 11:51:36 AM PDT, Ruben Wauters <rubenru09@....com>
> 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>
> > ---
> > 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
> > 
> 
> strscpy() needs a buffer length; this patch wouldn't even compile!

Hi, this is incorrect, strscpy is defined in string.h as
#define strscpy(dst, src, ...)	\
	CONCATENATE(__strscpy, COUNT_ARGS(__VA_ARGS__))(dst, src,
__VA_ARGS__)

the third parameter is optional, and it works perfectly fine with two
parameters. I have compiled it, and there are no errors.

> Not to mention that the string in question is generated in such a way
> that cannot be unterminated.

I'm not entirely sure what you mean here? The assignments above are
null terminated strings, which the two parameter version works fine
with.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ