linux-kernel - RE: [PATCH] block: fix length of 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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Tue, 2 Jan 2024 09:14:15 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Guoxin Pu' <pugokushin@...il.com>, "axboe@...nel.dk" <axboe@...nel.dk>
CC: "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH] block: fix length of strscpy()

From: Guoxin Pu 
> Sent: 02 January 2024 02:31
> 
> Thank you for the review. Sorry if this is the duplicated reply, as I
> didn't configure my mail client to send text-only message and the
> previous mail was rejected by the list.
> 
> On 02/01/2024 05:47, David Laight wrote:
> >> @@ -79,8 +79,8 @@ static int parse_subpart(struct cmdline_subpart **subpart, char *partdef)
> >>   			goto fail;
> >>   		}
> >>
> >> -		length = min_t(int, next - partdef,
> >> -			       sizeof(new_subpart->name) - 1);
> >> +		length = min_t(int, next - partdef + 1,
> >> +			       sizeof(new_subpart->name));
> >>   		strscpy(new_subpart->name, partdef, length);
> > Shouldn't that be a memcpy() with the original length?
> > Since it looks as though there is something equivalent to:
> > 		next = strchr(partdef, ',');
> > just above?
> > Maybe with:
> > 		new_subpart->name[length] = '\0';
> > if the target isn't zero filled (which the strncpy() probably
> > relied on.)
> 
> Yes that would be better. But since I'm fixing the issue caused by the
> mentioned commit, which was an accepted change to use strscpy instead of
> strncpy and seems a part of a series of changes to do that, I think
> there might be a reason the maintainers preferred strscpy over strncpy
> over memcpy? Otherwise we could just revert that commit and keep using
> the original strncpy + setting NULL method, and then potentially swap
> strncpy with memcpy.

I suspect they accepted the change without realising just how
creative some of the strncpy() calls are.
While strscpy() is a better function than strncpy() (or strlcpy())
extreme care has to be taken to avoid adding bugs to code that
was actually fine.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)