[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c278bbd3-c024-41ea-8640-d7bf7e8cff47@harmstone.com>
Date: Thu, 19 Jun 2025 18:03:11 +0100
From: Mark Harmstone <mark@...mstone.com>
To: Brahmajit Das <listout@...tout.xyz>, linux-hardening@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-btrfs@...r.kernel.org
Cc: clm@...com, josef@...icpanda.com, dsterba@...e.com, kees@...nel.org
Subject: Re: [PATCH] btrfs: replace deprecated strcpy with strscpy
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.
> ...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
Powered by blists - more mailing lists