linux-kernel - Re: [PATCH] btrfs: 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: <20250620122454.GQ4037@twin.jikos.cz>
Date: Fri, 20 Jun 2025 14:24:54 +0200
From: David Sterba <dsterba@...e.cz>
To: Brahmajit Das <listout@...tout.xyz>
Cc: Mark Harmstone <mark@...mstone.com>, linux-hardening@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-btrfs@...r.kernel.org,
	clm@...com, josef@...icpanda.com, dsterba@...e.com, kees@...nel.org
Subject: Re: [PATCH] btrfs: replace deprecated strcpy with strscpy

On Thu, Jun 19, 2025 at 11:32:58PM +0530, Brahmajit Das wrote:
> On 19.06.2025 18:03, Mark Harmstone wrote:
> > On 19/06/2025 3.06 pm, Brahmajit Das 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.
> > 
> > I think calling strcpy "deprecated" is a bit tendentious. IMHO the way to proceed
> > is to use KASAN, which catches the misuse of strcpy as well as other bugs.
> > 
> Understood, thanks for point it out.
> > > ...snip...
> > 
> > > --- a/fs/btrfs/volumes.c
> > > +++ b/fs/btrfs/volumes.c
> > > @@ -215,7 +215,7 @@ void btrfs_describe_block_groups(u64 bg_flags, char *buf, u32 size_buf)
> > >   	u32 size_bp = size_buf;
> > >   	if (!flags) {
> > > -		strcpy(bp, "NONE");
> > > +		memcpy(bp, "NONE", 4);
> > >   		return;
> > >   	}
> > 
> > These aren't equivalent. strcpy copies the source plus its trailing null - the
> > equivalent would be memcpy(bp, "NONE", 4). So 4 here should really be 5 - but
> > you shouldn't be hardcoding magic numbers anyway.
> > 
> > On top of that memcpy is just as "unsafe" as strcpy, so there's no benefit to
> > this particular change. gcc -O2 compiles it the same way anyway:
> > https://godbolt.org/z/8fEaKTTzo
> > 
> > Mark
> > 
> 
> I was planning to use strscpy, but it doesn't work with char pointers,
> hence went with memcpy. If you or anyone has a better approach for this,
> I'm more than happy to send that as a v3.

As the code is structured, you can move "NONE" as initial value of buf
in describe_relocation() and just return from "if (!flags)".