linux-kernel - Re: [PATCH] perf/x86: Replace strncpy() with memcpy() for vendor string

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: <aIA8yDYF_WJBxtxi@google.com>
Date: Tue, 22 Jul 2025 18:37:12 -0700
From: Namhyung Kim <namhyung@...nel.org>
To: Usman Akinyemi <usmanakinyemi202@...il.com>
Cc: James Clark <james.clark@...aro.org>,
	David Laight <david.laight.linux@...il.com>, peterz@...radead.org,
	mingo@...hat.com, acme@...nel.org, mark.rutland@....com,
	alexander.shishkin@...ux.intel.com, jolsa@...nel.org,
	irogers@...gle.com, adrian.hunter@...el.com,
	kan.liang@...ux.intel.com, linux-perf-users@...r.kernel.org,
	linux-kernel@...r.kernel.org, skhan@...uxfoundation.org,
	linux-kernel-mentees@...ts.linux.dev
Subject: Re: [PATCH] perf/x86: Replace strncpy() with memcpy() for vendor
 string

Hello,

On Thu, Jul 10, 2025 at 07:03:07PM +0530, Usman Akinyemi wrote:
> On Fri, Jul 4, 2025 at 6:17 PM Usman Akinyemi
> <usmanakinyemi202@...il.com> wrote:
> >
> > On Fri, Jul 4, 2025 at 4:40 PM James Clark <james.clark@...aro.org> wrote:
> > >
> > >
> > >
> > > On 04/07/2025 10:20 am, David Laight wrote:
> > > > On Thu, 19 Jun 2025 03:28:43 +0530
> > > > Usman Akinyemi <usmanakinyemi202@...il.com> wrote:
> > > >
> > > >> strncpy() is unsafe for fixed-size binary data as
> > > >> it may not NUL-terminate and is deprecated for such
> > >
> > > But memcpy doesn't null terminate after the 4 chars either so I don't
> > > think that's a good justification. Surely you don't want null
> > > termination, because char *vendor is supposed to be a single string
> > > without extra nulls in the middle. It specifically adds a null at the
> > > end of the function.
> > >
> > > >> usage. Since we're copying raw CPUID register values,
> > > >> memcpy() is the correct and safe choice.
> > > >>
> > >
> > > There should be a fixes: tag here if it actually fixes something. But in
> > > this use case strncpy seems to behave identically to memcpy so I don't
> > > think we should change it. Except maybe if b,c,d have NULLs in them then
> > > strncpy will give you uninitialized parts where memcpy won't. But that's
> > > not mentioned in the commit message and presumably it doesn't happen?
> >
> > Hi James,
> >
> > Thanks for the review.
> >
> > What you said is true, strncpy and memcpy seem to behave identically.
> >
> > I should have rephrased the commit message in a different way.
> > While strncpy seems to work here, firstly, it is an interface that has
> > been deprecated.
> > See -> https://github.com/KSPP/linux/issues/90.
> > Also, memcpy is semantically correct for copying raw data compared to
> > strncpy which is for string.
> >
> > I am not sure if the b, c, d can have a null byte, I think using the
> > semantically correct function (memcpy) improves the robustness even in
> > cases where b, c, d have null byte.
> >
> > What do you think?
> Hello,
> 
> This is a gentle follow-up on this patch.

Sorry for the delay.

> 
> I would like to know if I can send the updated patch series with the
> correct commit message.

I feel like the strncpy() is intentional and we don't want unexpected
NUL-termination in the middle.  If it has a NUL character then it should
be a short string and don't need the later part.

Thanks,
Namhyung