* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Willy Tarreau @ 2026-05-12 5:54 UTC (permalink / raw)
To: Greg KH
Cc: Jonathan Corbet, Leon Romanovsky, skhan, security, workflows,
linux-doc, linux-kernel
In-Reply-To: <2026051220-fetal-obituary-bb2b@gregkh>
On Tue, May 12, 2026 at 07:46:34AM +0200, Greg KH wrote:
> On Mon, May 11, 2026 at 02:42:14PM -0600, Jonathan Corbet wrote:
> > Willy Tarreau <w@1wt.eu> writes:
> >
> > >> I can ship stuff Linusward quickly too... :) But it's fine if Greg
> > >> takes it, of course.
> > >
> > > Oh that's fine then. I thought you only delivered such updates into next
> > > releases. I'm fine with either way of course! Let's pick the path of
> > > least effort for each.
> >
> > That's my normal procedure, since there are few docs changes that have
> > greater urgency, but I do have a "fixes" branch.
> >
> > Greg, what's your preference? Unless I hear otherwise, I guess I'll
> > apply it shortly.
>
> Please apply it and take it through your tree, thanks!
Thanks to you both!
Willy
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Greg KH @ 2026-05-12 5:46 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Willy Tarreau, Leon Romanovsky, skhan, security, workflows,
linux-doc, linux-kernel
In-Reply-To: <87a4u5u195.fsf@trenco.lwn.net>
On Mon, May 11, 2026 at 02:42:14PM -0600, Jonathan Corbet wrote:
> Willy Tarreau <w@1wt.eu> writes:
>
> >> I can ship stuff Linusward quickly too... :) But it's fine if Greg
> >> takes it, of course.
> >
> > Oh that's fine then. I thought you only delivered such updates into next
> > releases. I'm fine with either way of course! Let's pick the path of
> > least effort for each.
>
> That's my normal procedure, since there are few docs changes that have
> greater urgency, but I do have a "fixes" branch.
>
> Greg, what's your preference? Unless I hear otherwise, I guess I'll
> apply it shortly.
Please apply it and take it through your tree, thanks!
greg k-h
^ permalink raw reply
* Re: [PATCH] docs: fix spelling of Shepherd in howto
From: Randy Dunlap @ 2026-05-12 0:41 UTC (permalink / raw)
To: Chen-Shi-Hong, corbet; +Cc: skhan, workflows, linux-doc, linux-kernel
In-Reply-To: <20260512000946.3234-1-eric039eric@gmail.com>
Hi,
On 5/11/26 5:09 PM, Chen-Shi-Hong wrote:
> Correct the spelling of "Shepherd" in the acknowledgements section of
> Documentation/process/howto.rst.
How do you know that the last name is misspelled?
I found email from "Alex Shepard" on lore.kernel.org/all/ but none from
Alex Shepherd.
https://lore.kernel.org/all/1137702713.3205.43.camel@athena.sea.amer.gettywan.com/
Names can often be spelled many ways.
> Signed-off-by: Chen-Shi-Hong <eric039eric@gmail.com>
> ---
> Documentation/process/howto.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
> index 9438e03d6f50..edf4412de112 100644
> --- a/Documentation/process/howto.rst
> +++ b/Documentation/process/howto.rst
> @@ -616,7 +616,7 @@ Huizenga for some of the list of things you should and should not say.
> Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
> Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi
> Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,
> -David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard for
> +David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepherd for
> their review, comments, and contributions. Without their help, this
> document would not have been possible.
>
>
> base-commit: 5d6919055dec134de3c40167a490f33c74c12581
--
~Randy
^ permalink raw reply
* [PATCH] docs: fix spelling of Shepherd in howto
From: Chen-Shi-Hong @ 2026-05-12 0:09 UTC (permalink / raw)
To: corbet; +Cc: skhan, workflows, linux-doc, linux-kernel, Chen-Shi-Hong
Correct the spelling of "Shepherd" in the acknowledgements section of
Documentation/process/howto.rst.
Signed-off-by: Chen-Shi-Hong <eric039eric@gmail.com>
---
Documentation/process/howto.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index 9438e03d6f50..edf4412de112 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -616,7 +616,7 @@ Huizenga for some of the list of things you should and should not say.
Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi
Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,
-David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard for
+David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepherd for
their review, comments, and contributions. Without their help, this
document would not have been possible.
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Jonathan Corbet @ 2026-05-11 20:42 UTC (permalink / raw)
To: Willy Tarreau
Cc: Greg KH, Leon Romanovsky, skhan, security, workflows, linux-doc,
linux-kernel
In-Reply-To: <agI7XogSmfN_Pm4t@1wt.eu>
Willy Tarreau <w@1wt.eu> writes:
>> I can ship stuff Linusward quickly too... :) But it's fine if Greg
>> takes it, of course.
>
> Oh that's fine then. I thought you only delivered such updates into next
> releases. I'm fine with either way of course! Let's pick the path of
> least effort for each.
That's my normal procedure, since there are few docs changes that have
greater urgency, but I do have a "fixes" branch.
Greg, what's your preference? Unless I hear otherwise, I guess I'll
apply it shortly.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH 1/2] [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: David Laight @ 2026-05-11 20:34 UTC (permalink / raw)
To: Kees Cook
Cc: Geert Uytterhoeven, Manuel Ebner, andy.shevchenko, apw, corbet,
dwaipayanray1, joe, linux-doc, linux-kernel, lukas.bulwahn, skhan,
workflows
In-Reply-To: <202605111206.ECA86141@keescook>
On Mon, 11 May 2026 12:07:38 -0700
Kees Cook <kees@kernel.org> wrote:
> On Mon, May 11, 2026 at 02:26:49PM +0100, David Laight wrote:
> > On Mon, 11 May 2026 13:40:55 +0200
> > Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > > Hi Manuel,
> > >
> > > On Sun, 10 May 2026 at 18:52, Manuel Ebner <manuelebner@mailbox.org> wrote:
> > > > add strlcat and alternatives
> > >
> > > Thanks for your patch!
> > >
> > > > --- a/Documentation/process/deprecated.rst
> > > > +++ b/Documentation/process/deprecated.rst
> > > > @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
> > > > though care must be given to any cases where the return value of strlcpy()
> > > > is used, since strscpy() will return negative errno values when it truncates.
> > > >
> > > > +strlcat()
> > > > +---------
> > > > +strlcat() must re-scan the destination string from the beginning on each
> > > > +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> > > > +snprintf() and scnprintf()
> > >
> > > The last two not only require the caller to keep track of the offset
> > > in the buffer, but also using "%s" when storing passed strings.
> >
> > Which also means they are significantly slower.
> > Mind you, some code has:
> > strlcat(buf, "\n", SIZE);
> > return strlen(buf);
> > which carefully scans the string twice.
> > Since the '\0' isn't always needed (eg 'show' functions), this can be:
> > len = strlen(buf);
> > buf[len] ='\n';
> > return len + 1;
> > Of course, the code could often easily get the length by other means.
>
> I think I'd prefer to only recommend using seq_buf API. Or for sysfs,
> sysfs_emit() as seq_buf hasn't been extended there yet.
True for the docs, but rather more work when you are just trying to
get rid of strcpy() and strcat() calls.
It can be hard working out whether you can use sysfs_emit() or not.
(And I recently failed to find where the PAGE_SIZE buffer is
actually allocated; I'm sure it should just be 4k.)
-- David
>
> -Kees
>
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Willy Tarreau @ 2026-05-11 20:26 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Greg KH, Leon Romanovsky, skhan, security, workflows, linux-doc,
linux-kernel
In-Reply-To: <878q9pvlif.fsf@trenco.lwn.net>
Hi Jon!
On Mon, May 11, 2026 at 12:39:20PM -0600, Jonathan Corbet wrote:
> Willy Tarreau <w@1wt.eu> writes:
>
> >>
> >> Looks great, thank you!
> >>
> >> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >>
> >> Want me to take it through one of my trees now to get it to Linus this
> >> week, or should it go through the documentation tree? Either is fine
> >> with me.
> >
> > Yes, please take it as usual, it's simpler for me and it will likely
> > allow it to be published ealier, which ultimately should help us
> > faster ;-)
>
> I can ship stuff Linusward quickly too... :) But it's fine if Greg
> takes it, of course.
Oh that's fine then. I thought you only delivered such updates into next
releases. I'm fine with either way of course! Let's pick the path of
least effort for each.
Thank you!
Willy
^ permalink raw reply
* Re: [PATCH 1/2] [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: Kees Cook @ 2026-05-11 19:07 UTC (permalink / raw)
To: David Laight
Cc: Geert Uytterhoeven, Manuel Ebner, andy.shevchenko, apw, corbet,
dwaipayanray1, joe, linux-doc, linux-kernel, lukas.bulwahn, skhan,
workflows
In-Reply-To: <20260511142649.463c3ea5@pumpkin>
On Mon, May 11, 2026 at 02:26:49PM +0100, David Laight wrote:
> On Mon, 11 May 2026 13:40:55 +0200
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> > Hi Manuel,
> >
> > On Sun, 10 May 2026 at 18:52, Manuel Ebner <manuelebner@mailbox.org> wrote:
> > > add strlcat and alternatives
> >
> > Thanks for your patch!
> >
> > > --- a/Documentation/process/deprecated.rst
> > > +++ b/Documentation/process/deprecated.rst
> > > @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
> > > though care must be given to any cases where the return value of strlcpy()
> > > is used, since strscpy() will return negative errno values when it truncates.
> > >
> > > +strlcat()
> > > +---------
> > > +strlcat() must re-scan the destination string from the beginning on each
> > > +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> > > +snprintf() and scnprintf()
> >
> > The last two not only require the caller to keep track of the offset
> > in the buffer, but also using "%s" when storing passed strings.
>
> Which also means they are significantly slower.
> Mind you, some code has:
> strlcat(buf, "\n", SIZE);
> return strlen(buf);
> which carefully scans the string twice.
> Since the '\0' isn't always needed (eg 'show' functions), this can be:
> len = strlen(buf);
> buf[len] ='\n';
> return len + 1;
> Of course, the code could often easily get the length by other means.
I think I'd prefer to only recommend using seq_buf API. Or for sysfs,
sysfs_emit() as seq_buf hasn't been extended there yet.
-Kees
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Jonathan Corbet @ 2026-05-11 18:39 UTC (permalink / raw)
To: Willy Tarreau, Greg KH
Cc: Leon Romanovsky, skhan, security, workflows, linux-doc,
linux-kernel
In-Reply-To: <agIZ8zeg3m0xE3yL@1wt.eu>
Willy Tarreau <w@1wt.eu> writes:
>>
>> Looks great, thank you!
>>
>> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>
>> Want me to take it through one of my trees now to get it to Linus this
>> week, or should it go through the documentation tree? Either is fine
>> with me.
>
> Yes, please take it as usual, it's simpler for me and it will likely
> allow it to be published ealier, which ultimately should help us
> faster ;-)
I can ship stuff Linusward quickly too... :) But it's fine if Greg
takes it, of course.
jon
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Willy Tarreau @ 2026-05-11 18:03 UTC (permalink / raw)
To: Greg KH
Cc: Leon Romanovsky, Jonathan Corbet, skhan, security, workflows,
linux-doc, linux-kernel
In-Reply-To: <2026051124-afar-renewal-795c@gregkh>
On Mon, May 11, 2026 at 07:28:57PM +0200, Greg KH wrote:
> On Sat, May 09, 2026 at 11:47:54AM +0200, Willy Tarreau wrote:
> > The use of automated tools to find bugs in random locations of the kernel
> > induces a raise of security reports even if most of them should just be
> > reported as regular bugs. This patch is an attempt at drawing a line
> > between what qualifies as a security bug and what does not, hoping to
> > improve the situation and ease decision on the reporter's side.
> >
> > It defers the enumeration to a new file, threat-model.rst, that tries
> > to enumerate various classes of issues that are and are not security
> > bugs. This should permit to more easily update this file for various
> > subsystem-specific rules without having to revisit the security bug
> > reporting guide.
> >
> > Cc: Greg KH <gregkh@linuxfoundation.org>
> > Cc: Leon Romanovsky <leon@kernel.org>
> > Suggested-by: Leon Romanovsky <leon@kernel.org>
> > Suggested-by: Greg KH <gregkh@linuxfoundation.org>
> > Reviewed-by: Leon Romanovsky <leon@kernel.org>
> > Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
> > Signed-off-by: Willy Tarreau <w@1wt.eu>
> > ---
> > Documentation/process/index.rst | 1 +
> > Documentation/process/security-bugs.rst | 38 +++-
> > Documentation/process/threat-model.rst | 236 ++++++++++++++++++++++++
> > 3 files changed, 274 insertions(+), 1 deletion(-)
> > create mode 100644 Documentation/process/threat-model.rst
>
> Looks great, thank you!
>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Want me to take it through one of my trees now to get it to Linus this
> week, or should it go through the documentation tree? Either is fine
> with me.
Yes, please take it as usual, it's simpler for me and it will likely
allow it to be published ealier, which ultimately should help us
faster ;-)
Thanks!
Willy
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Greg KH @ 2026-05-11 17:28 UTC (permalink / raw)
To: Willy Tarreau
Cc: Leon Romanovsky, Jonathan Corbet, skhan, security, workflows,
linux-doc, linux-kernel
In-Reply-To: <20260509094755.2838-3-w@1wt.eu>
On Sat, May 09, 2026 at 11:47:54AM +0200, Willy Tarreau wrote:
> The use of automated tools to find bugs in random locations of the kernel
> induces a raise of security reports even if most of them should just be
> reported as regular bugs. This patch is an attempt at drawing a line
> between what qualifies as a security bug and what does not, hoping to
> improve the situation and ease decision on the reporter's side.
>
> It defers the enumeration to a new file, threat-model.rst, that tries
> to enumerate various classes of issues that are and are not security
> bugs. This should permit to more easily update this file for various
> subsystem-specific rules without having to revisit the security bug
> reporting guide.
>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Leon Romanovsky <leon@kernel.org>
> Suggested-by: Leon Romanovsky <leon@kernel.org>
> Suggested-by: Greg KH <gregkh@linuxfoundation.org>
> Reviewed-by: Leon Romanovsky <leon@kernel.org>
> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> Documentation/process/index.rst | 1 +
> Documentation/process/security-bugs.rst | 38 +++-
> Documentation/process/threat-model.rst | 236 ++++++++++++++++++++++++
> 3 files changed, 274 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/process/threat-model.rst
Looks great, thank you!
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Want me to take it through one of my trees now to get it to Linus this
week, or should it go through the documentation tree? Either is fine
with me.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 2/2] scripts: checkpatch.pl: add warning for strlcat()
From: David Laight @ 2026-05-11 13:27 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Manuel Ebner, andy.shevchenko, apw, dwaipayanray1, joe, kees,
linux-doc, linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <87a4u6w3ez.fsf@trenco.lwn.net>
On Mon, 11 May 2026 06:12:36 -0600
Jonathan Corbet <corbet@lwn.net> wrote:
> Manuel Ebner <manuelebner@mailbox.org> writes:
>
> > add a warning for strlcat()
> >
> > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> > ---
> > scripts/checkpatch.pl | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 0492d6afc9a1..ca1a8e67d529 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -7085,6 +7085,12 @@ sub process {
> > "Prefer strscpy over strlcpy - see: https://github.com/KSPP/linux/issues/89\n" . $herecurr);
> > }
> >
> > +# strlcat uses that should likely be
> > + if ($line =~ /\bstrlcat\s*\(/ && !is_userspace($realfile)) {
> > + WARN("STRLCAT",
> > + "Prefer seq_buf_printf() over strlcat - see: https://github.com/KSPP/linux/issues/370\n" . $herecurr);
> > + }
>
> Using seq_buf_printf() requires switching over to the seq_buf API in
> general, it is not just a simple substitution, so this advice may prove
> unhelpful to many.
And I'm not sure the external url is a good idea.
>
> jon
>
^ permalink raw reply
* Re: [PATCH 1/2] [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: David Laight @ 2026-05-11 13:26 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Manuel Ebner, andy.shevchenko, apw, corbet, dwaipayanray1, joe,
kees, linux-doc, linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <CAMuHMdWchXXcMyShiMZrhFTrHoB-TcKQEBcRoCTJFpwJsxxdhg@mail.gmail.com>
On Mon, 11 May 2026 13:40:55 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Manuel,
>
> On Sun, 10 May 2026 at 18:52, Manuel Ebner <manuelebner@mailbox.org> wrote:
> > add strlcat and alternatives
>
> Thanks for your patch!
>
> > --- a/Documentation/process/deprecated.rst
> > +++ b/Documentation/process/deprecated.rst
> > @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
> > though care must be given to any cases where the return value of strlcpy()
> > is used, since strscpy() will return negative errno values when it truncates.
> >
> > +strlcat()
> > +---------
> > +strlcat() must re-scan the destination string from the beginning on each
> > +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> > +snprintf() and scnprintf()
>
> The last two not only require the caller to keep track of the offset
> in the buffer, but also using "%s" when storing passed strings.
Which also means they are significantly slower.
Mind you, some code has:
strlcat(buf, "\n", SIZE);
return strlen(buf);
which carefully scans the string twice.
Since the '\0' isn't always needed (eg 'show' functions), this can be:
len = strlen(buf);
buf[len] ='\n';
return len + 1;
Of course, the code could often easily get the length by other means.
-- David
>
> I hope we won't see mindless conversions lacking the "%s",
> introducing new security issues:
>
> -strlcat(buf, s, size);
> +scnprintf(buf + off, size - off, s);
>
> > +
> > %p format specifier
> > -------------------
> > Traditionally, using "%p" in format strings would lead to regular address
>
> Gr{oetje,eeting}s,
>
> Geert
>
^ permalink raw reply
* Re: [PATCH 2/2] scripts: checkpatch.pl: add warning for strlcat()
From: Jonathan Corbet @ 2026-05-11 12:12 UTC (permalink / raw)
To: Manuel Ebner, manuelebner
Cc: andy.shevchenko, apw, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260510165649.57880-2-manuelebner@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
> add a warning for strlcat()
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> ---
> scripts/checkpatch.pl | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 0492d6afc9a1..ca1a8e67d529 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -7085,6 +7085,12 @@ sub process {
> "Prefer strscpy over strlcpy - see: https://github.com/KSPP/linux/issues/89\n" . $herecurr);
> }
>
> +# strlcat uses that should likely be
> + if ($line =~ /\bstrlcat\s*\(/ && !is_userspace($realfile)) {
> + WARN("STRLCAT",
> + "Prefer seq_buf_printf() over strlcat - see: https://github.com/KSPP/linux/issues/370\n" . $herecurr);
> + }
Using seq_buf_printf() requires switching over to the seq_buf API in
general, it is not just a simple substitution, so this advice may prove
unhelpful to many.
jon
^ permalink raw reply
* Re: [PATCH 1/2] [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: Geert Uytterhoeven @ 2026-05-11 11:40 UTC (permalink / raw)
To: Manuel Ebner
Cc: andy.shevchenko, apw, corbet, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260510165159.57457-2-manuelebner@mailbox.org>
Hi Manuel,
On Sun, 10 May 2026 at 18:52, Manuel Ebner <manuelebner@mailbox.org> wrote:
> add strlcat and alternatives
Thanks for your patch!
> --- a/Documentation/process/deprecated.rst
> +++ b/Documentation/process/deprecated.rst
> @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
> though care must be given to any cases where the return value of strlcpy()
> is used, since strscpy() will return negative errno values when it truncates.
>
> +strlcat()
> +---------
> +strlcat() must re-scan the destination string from the beginning on each
> +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> +snprintf() and scnprintf()
The last two not only require the caller to keep track of the offset
in the buffer, but also using "%s" when storing passed strings.
I hope we won't see mindless conversions lacking the "%s",
introducing new security issues:
-strlcat(buf, s, size);
+scnprintf(buf + off, size - off, s);
> +
> %p format specifier
> -------------------
> Traditionally, using "%p" in format strings would lead to regular address
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: Randy Dunlap @ 2026-05-10 17:32 UTC (permalink / raw)
To: Manuel Ebner
Cc: andy.shevchenko, apw, corbet, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260510165451.57674-2-manuelebner@mailbox.org>
On 5/10/26 9:54 AM, Manuel Ebner wrote:
> add strlcat and alternatives
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> ---
> Documentation/process/deprecated.rst | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
> index fed56864d036..b8a65c19796c 100644
> --- a/Documentation/process/deprecated.rst
> +++ b/Documentation/process/deprecated.rst
> @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
> though care must be given to any cases where the return value of strlcpy()
> is used, since strscpy() will return negative errno values when it truncates.
>
> +strlcat()
> +---------
> +strlcat() must re-scan the destination string from the beginning on each
> +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> +snprintf() and scnprintf()
Add an ending period.
> +
> %p format specifier
> -------------------
> Traditionally, using "%p" in format strings would lead to regular address
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/2] scripts: checkpatch.pl: add warning for strlcat()
From: Randy Dunlap @ 2026-05-10 17:31 UTC (permalink / raw)
To: Manuel Ebner
Cc: andy.shevchenko, apw, corbet, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260510165649.57880-2-manuelebner@mailbox.org>
On 5/10/26 9:56 AM, Manuel Ebner wrote:
> add a warning for strlcat()
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> ---
> scripts/checkpatch.pl | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 0492d6afc9a1..ca1a8e67d529 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -7085,6 +7085,12 @@ sub process {
> "Prefer strscpy over strlcpy - see: https://github.com/KSPP/linux/issues/89\n" . $herecurr);
> }
>
> +# strlcat uses that should likely be
should likely be what?
> + if ($line =~ /\bstrlcat\s*\(/ && !is_userspace($realfile)) {
> + WARN("STRLCAT",
> + "Prefer seq_buf_printf() over strlcat - see: https://github.com/KSPP/linux/issues/370\n" . $herecurr);
> + }
> +
> # strncpy uses that should likely be strscpy or strscpy_pad
> if ($line =~ /\bstrncpy\s*\(/ && !is_userspace($realfile)) {
> WARN("STRNCPY",
--
~Randy
^ permalink raw reply
* [PATCH 2/2] scripts: checkpatch.pl: add warning for strlcat()
From: Manuel Ebner @ 2026-05-10 16:56 UTC (permalink / raw)
To: manuelebner
Cc: andy.shevchenko, apw, corbet, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260510164907.57176-2-manuelebner@mailbox.org>
add a warning for strlcat()
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
scripts/checkpatch.pl | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 0492d6afc9a1..ca1a8e67d529 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -7085,6 +7085,12 @@ sub process {
"Prefer strscpy over strlcpy - see: https://github.com/KSPP/linux/issues/89\n" . $herecurr);
}
+# strlcat uses that should likely be
+ if ($line =~ /\bstrlcat\s*\(/ && !is_userspace($realfile)) {
+ WARN("STRLCAT",
+ "Prefer seq_buf_printf() over strlcat - see: https://github.com/KSPP/linux/issues/370\n" . $herecurr);
+ }
+
# strncpy uses that should likely be strscpy or strscpy_pad
if ($line =~ /\bstrncpy\s*\(/ && !is_userspace($realfile)) {
WARN("STRNCPY",
--
2.54.0
^ permalink raw reply related
* [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: Manuel Ebner @ 2026-05-10 16:54 UTC (permalink / raw)
To: manuelebner
Cc: andy.shevchenko, apw, corbet, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260510164907.57176-2-manuelebner@mailbox.org>
add strlcat and alternatives
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
Documentation/process/deprecated.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
index fed56864d036..b8a65c19796c 100644
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
though care must be given to any cases where the return value of strlcpy()
is used, since strscpy() will return negative errno values when it truncates.
+strlcat()
+---------
+strlcat() must re-scan the destination string from the beginning on each
+call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
+snprintf() and scnprintf()
+
%p format specifier
-------------------
Traditionally, using "%p" in format strings would lead to regular address
--
2.54.0
^ permalink raw reply related
* [PATCH 1/2] [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: Manuel Ebner @ 2026-05-10 16:52 UTC (permalink / raw)
To: manuelebner
Cc: andy.shevchenko, apw, corbet, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260510164907.57176-2-manuelebner@mailbox.org>
add strlcat and alternatives
---
Documentation/process/deprecated.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
index fed56864d036..b8a65c19796c 100644
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
though care must be given to any cases where the return value of strlcpy()
is used, since strscpy() will return negative errno values when it truncates.
+strlcat()
+---------
+strlcat() must re-scan the destination string from the beginning on each
+call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
+snprintf() and scnprintf()
+
%p format specifier
-------------------
Traditionally, using "%p" in format strings would lead to regular address
--
2.54.0
^ permalink raw reply related
* [PATCH 0/2] Doc, scripts: facilitate phaseout of strlcat
From: Manuel Ebner @ 2026-05-10 16:49 UTC (permalink / raw)
To: Andy Shevchenko, Kees Cook, Jonathan Corbet, Shuah Khan,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
open list:DOCUMENTATION PROCESS, open list:DOCUMENTATION,
open list
Cc: Manuel Ebner
The goal of this series is to facilitate the transition from strlcat to better
alternatives.
^ permalink raw reply
* Re: [PATCH 4/5] docs: fix repeated prepositions across documentation
From: Randy Dunlap @ 2026-05-09 20:41 UTC (permalink / raw)
To: Andrew Lunn
Cc: Shuah Khan, Adrien Reynard, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino,
Jonathan Corbet, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Richard Weinberger, Anton Ivanov,
Johannes Berg, open list:KASAN, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list,
open list:NETWORKING [GENERAL], open list:USER-MODE LINUX (UML)
In-Reply-To: <3b4357a7-f70d-41b0-a75d-c30f9fb7dd98@lunn.ch>
On 5/9/26 12:39 PM, Andrew Lunn wrote:
>>> Can we get the tool changed to add a warning, something like:
>>>
>>> WARNING: This tool uses very simple pattern matching to look for
>>> repeated words. It does not understand the complexity of English,
>>> and will often result in false positive reports. Please assume it is
>>> wrong until proven otherwise.
>>
>> There was no commit log and no cover letter AFAIK.
>> Do we know what tool was used?
>>
>> Adrien, how did you discover these repeated words?
>>
>> (If it's my script from 2021, I'll gladly update it.)
Adrien is not using my script -- they developed their own script.
> Thinking about it some more, i think the warning might actually need
> to be different.
>
> If this tool has been around since 2021, all the real problems have
> been solved, leaving only the false positives. So the warning probably
> needs to be much stronger, saying that it probably only reports false
> positives, unless the code is new.
Makes some sense.
> Maybe we also want to extend the tool to have a list all the known
> false positives?
I'm not crazy about that one. And we have no evidence that I am aware
of that my script is causing any of these patches.
--
~Randy
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Shuah Khan @ 2026-05-09 19:51 UTC (permalink / raw)
To: Willy Tarreau, greg
Cc: Leon Romanovsky, Jonathan Corbet, security, workflows, linux-doc,
linux-kernel, Greg KH, Shuah Khan
In-Reply-To: <20260509094755.2838-3-w@1wt.eu>
On 5/9/26 03:47, Willy Tarreau wrote:
> The use of automated tools to find bugs in random locations of the kernel
> induces a raise of security reports even if most of them should just be
> reported as regular bugs. This patch is an attempt at drawing a line
> between what qualifies as a security bug and what does not, hoping to
> improve the situation and ease decision on the reporter's side.
>
> It defers the enumeration to a new file, threat-model.rst, that tries
> to enumerate various classes of issues that are and are not security
> bugs. This should permit to more easily update this file for various
> subsystem-specific rules without having to revisit the security bug
> reporting guide.
>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Leon Romanovsky <leon@kernel.org>
> Suggested-by: Leon Romanovsky <leon@kernel.org>
> Suggested-by: Greg KH <gregkh@linuxfoundation.org>
> Reviewed-by: Leon Romanovsky <leon@kernel.org>
> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> Documentation/process/index.rst | 1 +
> Documentation/process/security-bugs.rst | 38 +++-
> Documentation/process/threat-model.rst | 236 ++++++++++++++++++++++++
> 3 files changed, 274 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/process/threat-model.rst
>
Looks good to me.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH v2 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Shuah Khan @ 2026-05-09 19:50 UTC (permalink / raw)
To: Willy Tarreau
Cc: greg, leon, security, Jonathan Corbet, workflows, linux-doc,
linux-kernel, Greg KH, Shuah Khan
In-Reply-To: <af68uG2YIoYqnKbZ@1wt.eu>
On 5/8/26 22:48, Willy Tarreau wrote:
> Hi Shuah,
>
> On Fri, May 08, 2026 at 02:52:13PM -0600, Shuah Khan wrote:
>>> +What qualifies as a security bug
>>> +--------------------------------
>>> +
>>> +It is important that most bugs are handled publicly so as to involve the widest
>>> +possible audience and find the best solution. By nature, bugs that are handled
>>> +in closed discussions between a small set of participants are less likely to
>>> +produce the best possible fix (e.g., risk of missing valid use cases, limited
>>> +testing abilities).
>>> +
>>> +It turns out that the majority of the bugs reported via the security team are
>>> +just regular bugs that have been improperly qualified as security bugs due to
>>> +ignorance or misunderstanding of the Linux kernel's threat model described in
>>
>> "lack of understanding" instead of ignorance?
>
> I already had "misunderstanding", here I wanted to express the idea that
> people could simply ignore that this file exists (since it's new). Do you
> think we shouldn't care about this and just keep "misunderstanding" ?
>
> (...)
>>> +The Linux Kernel threat model
>>> +=============================
>>> +
>>> +There are a lot of assumptions regarding what the kernel protects against and
>>> +what it does not protect against. These assumptions tend to cause confusion for
>>
>> Could simply say "what it does not" or "what the kernel does and does not protect
>> against"
>
> Ah OK good point, I'll rephrase it.
>
>>> +* **Configuration**:
>>> +
>>> + * outdated kernels and particularly end-of-life branches are out of the scope
>>> + of the kernel's threat model: administrators are responsible for keeping
>>> + their system up to date. For a bug to qualify as a security bug, it must be
>>> + demonstrated that it affects actively maintained versions.
>>> +
>>> + * build-level: changes to the kernel configuration that are explicitly
>>> + documented as lowering the security level (e.g. ``CONFIG_NOMMU``), or
>>> + targeted at developers only.
>>> +
>>> + * OS-level: changes to command line parameters, sysctls, filesystem
>>> + permissions, user capabilities, exposure of privileged interfaces, that
>>> + explicitly increase exposure by either offering non-default access to
>>> + unprivileged users, or reduce the kernel's ability to enforce some
>>> + protections or mitigations. Example: write access to procfs or debugfs.
>>> +
>>> + * issues triggered only when using features intended for development or
>>> + debugging (e.g., lockdep, KASAN, fault-injection): these features are known
>>> + to introduce overhead and potential instability and are not intended for
>>> + production use.
>>
>> Can we call out features and tools (the ones in kernel repo)
>
> Sure!
>
>> sched_ext's Kconfig enables
>> a few debug options including LOCKDEP
>>
>> tools/sched_ext/Kconfig:CONFIG_DEBUG_LOCKDEP=y
>
> It's still there but maybe not visible enough, I should probably write
> it in upper case:
>
> debugging (e.g., lockdep, KASAN, fault-injection):
>
>>> +* **Excess of initial privileges**:
>>> +
>>> + * actions performed by a user already possessing the privileges required to
>>> + perform that action or modify that state (e.g. ``CAP_SYS_ADMIN``,
>>> + ``CAP_NET_ADMIN``, ``CAP_SYS_RAWIO``, ``CAP_SYS_MODULE`` with no further
>>> + boundary being crossed).
>>> +
>>> + * actions performed in user namespace without permitting anything in the
>>> + initial namespace that was not already permitted to the same user there.
>>
>> This was a bit hard to parse - examples might help here
>
> Yeah when rereading it now, I fully agree. I think I should avoid the
> double negation here and use a form such as;
>
> * actions performed in user namespace that do not bypass the restrictions
> imposed to the initial user.
>
> If examples are still needed, I could possibly add: "(e.g. ptrace, signals,
> FS or device access, system/network configuration, network binding)".
>
>>> + * anything performed by the root user in the initial namespace (e.g. kernel
>>> + oops when writing to a privileged device).
>>> +
>>> +* **Out of production use**:
>>> +
>>> + This covers theoretical/probabilistic attacks that rely on laboratory
>>> + conditions with zero system noise, or those requiring an unrealistic number
>>> + of attempts (e.g., billions of trials) that would be detected by standard
>>> + system monitoring long before success, such as:
>>> +
>>> + * prediction of random numbers that only works in a totally silent
>>> + environment (such as IP ID, TCP ports or sequence numbers that can only be
>>> + guessed in a lab).
>>> +
>>> + * activity observation and information leaks based on probabilistic
>>> + approaches that are prone to measurement noise and not realistically
>>> + reproducible on a production system.
>>> +
>>> + * issues that can only be triggered by heavy attacks (e.g. brute force) whose
>>> + impact on the system makes it unlikely or impossible to remain undetected
>>> + before they succeed (e.g. consuming all memory before succeeding).
>>> +
>>> + * problems seen only under development simulators, emulators, or combinations
>>> + that do not exist on real systems at the time of reporting (issues
>>> + involving tens of millions of threads, tens of thousands of CPUs,
>>> + unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds.
>>> +
>>> + * issues whose reproduction requires hardware modification or emulation,
>>> + including fake USB devices that pretend to be another one.
>>> +
>>> + * as well as issues that can be triggered at a cost that is orders of
>>> + magnitude higher than the expected benefits (e.g. fully functional keyboard
>>> + emulator only to retrieve 7 uninitialized bytes in a structure, or
>>> + brute-force method involving millions of connection attempts to guess a
>>> + port number).
>>
>> Can we add a section about problems found using experimental or tools
>> in development stage?
>
> You mean one more paragraph about CONFIG_EXPERIMENTAL ? Or what else do
> you have in mind ? Do not hesiate to propose a paragraph if you have
> anything in mind!
This is what I have in mind:
issues found by closed source static and dynamic checkers that are
in development by individual or research groups.
I see that you sent out v3 and we can add this later. My Reviewed-by
hold for your v3.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH 4/5] docs: fix repeated prepositions across documentation
From: Andrew Lunn @ 2026-05-09 19:39 UTC (permalink / raw)
To: Randy Dunlap
Cc: Shuah Khan, Adrien Reynard, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino,
Jonathan Corbet, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Richard Weinberger, Anton Ivanov,
Johannes Berg, open list:KASAN, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list,
open list:NETWORKING [GENERAL], open list:USER-MODE LINUX (UML)
In-Reply-To: <27c61395-f04f-420c-9a84-7e27773f2027@infradead.org>
> > Can we get the tool changed to add a warning, something like:
> >
> > WARNING: This tool uses very simple pattern matching to look for
> > repeated words. It does not understand the complexity of English,
> > and will often result in false positive reports. Please assume it is
> > wrong until proven otherwise.
>
> There was no commit log and no cover letter AFAIK.
> Do we know what tool was used?
>
> Adrien, how did you discover these repeated words?
>
> (If it's my script from 2021, I'll gladly update it.)
Thinking about it some more, i think the warning might actually need
to be different.
If this tool has been around since 2021, all the real problems have
been solved, leaving only the false positives. So the warning probably
needs to be much stronger, saying that it probably only reports false
positives, unless the code is new.
Maybe we also want to extend the tool to have a list all the known
false positives?
Andrew
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox