From: Mark Harmstone <mark@harmstone.com>
To: Brahmajit Das <listout@listout.xyz>,
linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-btrfs@vger.kernel.org
Cc: clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, kees@kernel.org
Subject: Re: [PATCH] btrfs: replace deprecated strcpy with strscpy
Date: Thu, 19 Jun 2025 18:03:11 +0100 [thread overview]
Message-ID: <c278bbd3-c024-41ea-8640-d7bf7e8cff47@harmstone.com> (raw)
In-Reply-To: <20250619140623.3139-1-listout@listout.xyz>
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
next prev parent reply other threads:[~2025-06-19 17:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-19 14:06 [PATCH] btrfs: replace deprecated strcpy with strscpy Brahmajit Das
2025-06-19 15:39 ` [PATCH v2] " Brahmajit Das
2025-06-19 17:06 ` Mark Harmstone
2025-06-19 17:59 ` Brahmajit Das
2025-06-19 18:03 ` Mark Harmstone
2025-06-20 1:43 ` [PATCH v3] " Brahmajit Das
2025-06-20 5:15 ` Mark Harmstone
2025-06-20 12:27 ` David Sterba
2025-06-19 17:03 ` Mark Harmstone [this message]
2025-06-19 18:02 ` [PATCH] " Brahmajit Das
2025-06-20 12:24 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c278bbd3-c024-41ea-8640-d7bf7e8cff47@harmstone.com \
--to=mark@harmstone.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=kees@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=listout@listout.xyz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.