linux-hardening - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <gsykswmdo5yusthxun4y5duhim6etxirrfezq6o6w4tlalcvxp@3wqjjzurypzc>
Date: Thu, 19 Jun 2025 23:32:58 +0530
From: Brahmajit Das <listout@...tout.xyz>
To: Mark Harmstone <mark@...mstone.com>
Cc: 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 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.
-- 
Regards,
listout