From: David Laight <david.laight.linux@gmail.com>
To: Andreas Hindborg <a.hindborg@kernel.org>
Cc: Kees Cook <kees@kernel.org>,
linux-hardening@vger.kernel.org, Arnd Bergmann <arnd@kernel.org>,
linux-kernel@vger.kernel.org, Breno Leitao <leitao@debian.org>
Subject: Re: [PATCH next] fs: Replace strcpy(s, "../") with memcpy(s, "../", 4)
Date: Fri, 19 Jun 2026 14:34:38 +0100 [thread overview]
Message-ID: <20260619143438.495c1780@pumpkin> (raw)
In-Reply-To: <874iiyg5kj.fsf@t14s.mail-host-address-is-not-set>
On Fri, 19 Jun 2026 12:58:20 +0200
Andreas Hindborg <a.hindborg@kernel.org> wrote:
> <david.laight.linux@gmail.com> writes:
>
> > From: David Laight <david.laight.linux@gmail.com>
> >
> > The code has already checked there is enough room.
> > Use memcpy() to avoid compiler warnings from possibly unbounded strcpy().
> >
> > Signed-off-by: David Laight <david.laight.linux@gmail.com>
> > ---
> > This is one of a group of patches that remove potentially unbounded
> > strcpy() calls.
> >
> > They are mostly replaced by strscpy() or, when strlen() has just been
> > called, with memcpy() (usually including the '\0').
> >
> > Calls with copy string literals into arrays are left unchanged.
> > They are safe and easily detected as such.
> >
> > The changes were made by getting the compiler to detect the calls and
> > then fixing the code by hand.
> >
> > Note that all the changes are only compile tested.
> >
> > Some Makefiles were changed to allow files to contain strcpy().
> > As well as 'difficult to fix' files, this included 'show' functions
> > as they really need to use sysfs_emit() or seq_printf().
> >
> > All the patches are being sent individually to avoid very long cc lists.
> > Apologies for the terse commit messages and likely unexpected tags.
> > (There are about 100 patches in total.)
> >
> > fs/configfs/symlink.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/configfs/symlink.c b/fs/configfs/symlink.c
> > index f3f79c67add5..9f36699e5922 100644
> > --- a/fs/configfs/symlink.c
> > +++ b/fs/configfs/symlink.c
> > @@ -67,7 +67,7 @@ static int configfs_get_target_path(struct config_item *item,
> > pr_debug("%s: depth = %d, size = %d\n", __func__, depth, size);
> >
> > for (s = path; depth--; s += 3)
> > - strcpy(s,"../");
> > + memcpy(s, "../", 4);
>
> I don't think this transform makes sense when copying string literals.
> The post transform code has one more foot gun than the original code.
They are actually identical, the compiler converts the former to the latter.
I was trying to remove all the strcpy() where the target isn't an array.
The initial check also only allowed string literals - but I relaxed that
a bit to reduce the number of false positives.
Were a similar check for calls to strcpy() be committed this code would
need changing, but you want something that ends up being a (misaligned)
32bit write of a constant on most architectures.
I just looked at the code again, the final '- 1' on the 'size = ...'
line looks very odd.
I wonder if it would be simpler to merge all three functions into
something with a single loop that builds the name/name part backwards
from the end of the buffer while adding "../" on the front and then
calling memmove() to put the two together.
David
>
> Best regards,
> Andreas Hindborg
>
>
>
prev parent reply other threads:[~2026-06-19 13:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CnPdNyUGjsYpAP8JdysfUf4wkBkm2a923cQ1hE4-mg0sUnJIm4Uj-cAkdVHswEsuZ3d6vhmX5eil2zLmrkfl3A==@protonmail.internalid>
2026-06-06 20:25 ` [PATCH next] fs: Replace strcpy(s, "../") with memcpy(s, "../", 4) david.laight.linux
2026-06-19 10:58 ` Andreas Hindborg
2026-06-19 13:34 ` David Laight [this message]
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=20260619143438.495c1780@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=arnd@kernel.org \
--cc=kees@kernel.org \
--cc=leitao@debian.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.