From: Linus Torvalds <torvalds@linux-foundation.org>
To: Justin Stitt <justinstitt@google.com>
Cc: Christoph Hellwig <hch@lst.de>, Kees Cook <keescook@chromium.org>,
Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@kernel.dk>,
Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org, ksummit@lists.linux.dev
Subject: Re: the nul-terminated string helper desk chair rearrangement
Date: Fri, 20 Oct 2023 10:56:31 -0700 [thread overview]
Message-ID: <CAHk-=wj4BZei4JTiX9qsAwk8PEKnPrvkG5FU0i_HNkcDpy7NGQ@mail.gmail.com> (raw)
In-Reply-To: <CAFhGd8o8FaD-3rkBAhEXhc8XqpUk_cLqNwyfpndVuSxDOei_gA@mail.gmail.com>
On Fri, 20 Oct 2023 at 10:40, Justin Stitt <justinstitt@google.com> wrote:
>
> There's some docs at [1]. Perhaps there could be more?
>
> [1]: https://elixir.bootlin.com/linux/v6.6-rc6/source/include/linux/fortify-string.h#L292
Note that we have so few 'strlcpy()' calls that we really should
remove that horrid horrid interface. It's a buggy piece of sh*t.
'strlcpy()' is fundamentally unsafe BY DESIGN if you don't trust the
source string - which is one of the alleged reasons to use it.
That said, while 'strscpy()' fixes the fundamental conceptual bugs of
strlcpy(), it's worth noting that it has *two* differences wrt
strlcpy:
- it doesn't have the broken return value
- it copies things in word-size chunks to be more efficient
And because of that word-size thing it will possibly insert more than
one NUL character at the end of the result.
To give an example, if you have
dst[64] = "abcdefghijklmnopqrstuvwxyz";
src[64] = "123\0........";
strlcpy(dst, src, 64);
then the strlcpy() will return 3 (the size of the copy), but the
destination will end up looking like
dst[64] = "123\0\0\0\0\0ijklmnopqrstuvwxyz...";
This odd "possibly word padding" is basically never relevant (and it's
obviously always also limited by the size you gave it), but *if* you
are doing something really odd, and you expect the end of the
destination string to not be modified at all past the final NUL of the
copy, you need to be aware of this.
It does mean that if you used to have
dst[4];
strlcpy(dst, "abc", 8);
then that *used* to work (because it would copy four bytes: "abc\0"
and that fits in 'dst[]'). But
dst[4];
strscpy(dst, "abc", 8);
will overflow dst[], because it will do a word-copy and you told
'strscpy()' that you had a 8-byte buffer, and it will try to write
"abc\0\0\0\0\0" into the destination.
The above is insane code, but it's an example of why a blind
strlcpy->strscpy conversion might change semantics.
Linus
next prev parent reply other threads:[~2023-10-20 17:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20231018-strncpy-drivers-nvme-host-fabrics-c-v1-1-b6677df40a35@google.com>
2023-10-19 5:46 ` the nul-terminated string helper desk chair rearrangement, was: Re: [PATCH] nvme-fabrics: replace deprecated strncpy with strscpy Christoph Hellwig
2023-10-19 6:01 ` the nul-terminated string helper desk chair rearrangement Kees Cook
2023-10-19 7:01 ` Willy Tarreau
2023-10-19 11:40 ` Alexey Dobriyan
2023-10-19 12:00 ` Willy Tarreau
2023-10-20 4:46 ` Christoph Hellwig
2023-10-20 17:40 ` Justin Stitt
2023-10-20 17:56 ` Linus Torvalds [this message]
2023-10-20 18:22 ` Kees Cook
2023-10-20 18:30 ` Kees Cook
2023-10-26 10:01 ` Christoph Hellwig
2023-10-26 11:39 ` James Bottomley
2023-10-26 13:52 ` Steven Rostedt
2023-10-26 13:59 ` Geert Uytterhoeven
2023-10-27 18:32 ` Alexey Dobriyan
2023-10-26 14:05 ` Jonathan Corbet
2023-10-27 7:08 ` Kalle Valo
2023-10-26 13:44 ` Andrew Lunn
2023-10-26 13:51 ` Laurent Pinchart
2023-10-26 14:27 ` James Bottomley
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='CAHk-=wj4BZei4JTiX9qsAwk8PEKnPrvkG5FU0i_HNkcDpy7NGQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=justinstitt@google.com \
--cc=kbusch@kernel.org \
--cc=keescook@chromium.org \
--cc=ksummit@lists.linux.dev \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox