* Re: [PATCH v2 0/3] Documentation: clarify required info in security reports
From: Willy Tarreau @ 2026-04-03 11:51 UTC (permalink / raw)
To: Greg KH
Cc: edumazet, rdunlap, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <2026040324-coping-vacation-7d64@gregkh>
On Fri, Apr 03, 2026 at 01:11:47PM +0200, Greg KH wrote:
> On Fri, Apr 03, 2026 at 08:20:15AM +0200, Willy Tarreau wrote:
> > Hi Greg,
> >
> > I'm sending you the doc clarifications we discussed for the process of
> > reporting security issues. It's cut into the 3 patches I shared this
> > morning on the security list (plus two typos fixed and a paragraph
> > asking for one single issue per report):
> >
> > - one patch that reminds our need for a valid e-mail address
> > - one that explains to reporters how to proceed to find maintainers
> > addresses, hoping we won't have to do it for 90% of reports anymore
> > - one that enumerates basic requirements for every report
> >
> > I think it covers the difficulties we've faced this week. As always,
> > we might possibly find tiny adjustments to add, but my goal would be
> > for such updates to be merged in time to update the public page ASAP
> > so that we can redirect incomplete reports in an attempt to lower the
> > team's current load.
>
> Looks great, thanks. I've applied these to one of my trees and will get
> them to Linus in time for 7.0-final.
Thank you!
Willy
^ permalink raw reply
* Re: [PATCH v2 0/3] Documentation: clarify required info in security reports
From: Greg KH @ 2026-04-03 11:11 UTC (permalink / raw)
To: Willy Tarreau
Cc: edumazet, rdunlap, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <20260403062018.31080-1-w@1wt.eu>
On Fri, Apr 03, 2026 at 08:20:15AM +0200, Willy Tarreau wrote:
> Hi Greg,
>
> I'm sending you the doc clarifications we discussed for the process of
> reporting security issues. It's cut into the 3 patches I shared this
> morning on the security list (plus two typos fixed and a paragraph
> asking for one single issue per report):
>
> - one patch that reminds our need for a valid e-mail address
> - one that explains to reporters how to proceed to find maintainers
> addresses, hoping we won't have to do it for 90% of reports anymore
> - one that enumerates basic requirements for every report
>
> I think it covers the difficulties we've faced this week. As always,
> we might possibly find tiny adjustments to add, but my goal would be
> for such updates to be merged in time to update the public page ASAP
> so that we can redirect incomplete reports in an attempt to lower the
> team's current load.
Looks great, thanks. I've applied these to one of my trees and will get
them to Linus in time for 7.0-final.
greg k-h
^ permalink raw reply
* [PATCH v2 3/3] Documentation: clarify the mandatory and desirable info for security reports
From: Willy Tarreau @ 2026-04-03 6:20 UTC (permalink / raw)
To: greg
Cc: edumazet, rdunlap, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau
In-Reply-To: <20260403062018.31080-1-w@1wt.eu>
A significant part of the effort of the security team consists in begging
reporters for patch proposals, or asking them to provide them in regular
format, and most of the time they're willing to provide this, they just
didn't know that it would help. So let's add a section detailing the
required and desirable contents in a security report to help reporters
write more actionable reports which do not require round trips.
Cc: Eric Dumazet <edumazet@google.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/process/security-bugs.rst | 66 ++++++++++++++++++++++---
1 file changed, 59 insertions(+), 7 deletions(-)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index ac97fc78fecd..0b1f6d8e3cbe 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -7,6 +7,65 @@ Linux kernel developers take security very seriously. As such, we'd
like to know when a security bug is found so that it can be fixed and
disclosed as quickly as possible.
+Preparing your report
+---------------------
+
+Like with any bug report, a security bug report requires a lot of analysis work
+from the developers, so the more information you can share about the issue, the
+better. Please review the procedure outlined in
+Documentation/admin-guide/reporting-issues.rst if you are unclear about what
+information is helpful. The following information are absolutely necessary in
+**any** security bug report:
+
+ * **affected kernel version range**: with no version indication, your report
+ will not be processed. A significant part of reports are for bugs that
+ have already been fixed, so it is extremely important that vulnerabilities
+ are verified on recent versions (development tree or latest stable
+ version), at least by verifying that the code has not changed since the
+ version where it was detected.
+
+ * **description of the problem**: a detailed description of the problem, with
+ traces showing its manifestation, and why you consider that the observed
+ behavior as a problem in the kernel, is necessary.
+
+ * **reproducer**: developers will need to be able to reproduce the problem to
+ consider a fix as effective. This includes both a way to trigger the issue
+ and a way to confirm it happens. A reproducer with low complexity
+ dependencies will be needed (source code, shell script, sequence of
+ instructions, file-system image etc). Binary-only executables are not
+ accepted. Working exploits are extremely helpful and will not be released
+ without consent from the reporter, unless they are already public. By
+ definition if an issue cannot be reproduced, it is not exploitable, thus it
+ is not a security bug.
+
+ * **conditions**: if the bug depends on certain configuration options,
+ sysctls, permissions, timing, code modifications etc, these should be
+ indicated.
+
+In addition, the following information are highly desirable:
+
+ * **suspected location of the bug**: the file names and functions where the
+ bug is suspected to be present are very important, at least to help forward
+ the report to the appropriate maintainers. When not possible (for example,
+ "system freezes each time I run this command"), the security team will help
+ identify the source of the bug.
+
+ * **a proposed fix**: bug reporters who have analyzed the cause of a bug in
+ the source code almost always have an accurate idea on how to fix it,
+ because they spent a long time studying it and its implications. Proposing
+ a tested fix will save maintainers a lot of time, even if the fix ends up
+ not being the right one, because it helps understand the bug. When
+ proposing a tested fix, please always format it in a way that can be
+ immediately merged (see Documentation/process/submitting-patches.rst).
+ This will save some back-and-forth exchanges if it is accepted, and you
+ will be credited for finding and fixing this issue. Note that in this case
+ only a ``Signed-off-by:`` tag is needed, without ``Reported-by:` when the
+ reporter and author are the same.
+
+ * **mitigations**: very often during a bug analysis, some ways of mitigating
+ the issue appear. It is useful to share them, as they can be helpful to
+ keep end users protected during the time it takes them to apply the fix.
+
Identifying contacts
--------------------
@@ -89,13 +148,6 @@ run additional tests. Reports where the reporter does not respond promptly
or cannot effectively discuss their findings may be abandoned if the
communication does not quickly improve.
-As it is with any bug, the more information provided the easier it
-will be to diagnose and fix. Please review the procedure outlined in
-'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
-information is helpful. Any exploit code is very helpful and will not
-be released without consent from the reporter unless it has already been
-made public.
-
The report must be sent to maintainers, with the security team in ``Cc:``.
The Linux kernel security team can be contacted by email at
<security@kernel.org>. This is a private list of security officers
--
2.52.0
^ permalink raw reply related
* [PATCH v2 2/3] Documentation: explain how to find maintainers addresses for security reports
From: Willy Tarreau @ 2026-04-03 6:20 UTC (permalink / raw)
To: greg
Cc: edumazet, rdunlap, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau
In-Reply-To: <20260403062018.31080-1-w@1wt.eu>
These days, 80% of the work done by the security team consists in
locating the affected subsystem in a report, running get_maintainers on
it, forwarding the report to these persons and responding to the reporter
with them in Cc. This is a huge and unneeded overhead that we must try to
lower for a better overall efficiency. This patch adds a complete section
explaining how to figure the list of recipients to send the report to.
Cc: Eric Dumazet <edumazet@google.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/process/security-bugs.rst | 76 ++++++++++++++++++++++++-
1 file changed, 73 insertions(+), 3 deletions(-)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index da7937fd59df..ac97fc78fecd 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -5,8 +5,75 @@ Security bugs
Linux kernel developers take security very seriously. As such, we'd
like to know when a security bug is found so that it can be fixed and
-disclosed as quickly as possible. Please report security bugs to the
-Linux kernel security team.
+disclosed as quickly as possible.
+
+Identifying contacts
+--------------------
+
+The most effective way to report a security bug is to send it directly to the
+affected subsystem's maintainers and Cc: the Linux kernel security team. Do
+not send it to a public list at this stage, unless you have good reasons to
+consider the issue as being public or trivial to discover (e.g. result of a
+widely available automated vulnerability scanning tool that can be repeated by
+anyone).
+
+If you're sending a report for issues affecting multiple parts in the kernel,
+even if they're fairly similar issues, please send individual messages (think
+that maintainers will not all work on the issues at the same time). The only
+exception is when an issue concerns closely related parts maintained by the
+exact same subset of maintainers, and these parts are expected to be fixed all
+at once by the same commit, then it may be acceptable to report them at once.
+
+One difficulty for most first-time reporters is to figure the right list of
+recipients to send a report to. In the Linux kernel, all official maintainers
+are trusted, so the consequences of accidentally including the wrong maintainer
+are essentially a bit more noise for that person, i.e. nothing dramatic. As
+such, a suitable method to figure the list of maintainers (which kernel
+security officers use) is to rely on the get_maintainers.pl script, tuned to
+only report maintainers. This script, when passed a file name, will look for
+its path in the MAINTAINERS file to figure a hierarchical list of relevant
+maintainers. Calling it a first time with the finest level of filtering will
+most of the time return a short list of this specific file's maintainers::
+
+ $ ./scripts/get_maintainer.pl --no-l --no-r --pattern-depth 1 \
+ drivers/example.c
+ Developer One <dev1@example.com> (maintainer:example driver)
+ Developer Two <dev2@example.org> (maintainer:example driver)
+
+These two maintainers should then receive the message. If the command does not
+return anything, it means the affected file is part of a wider subsystem, so we
+should be less specific::
+
+ $ ./scripts/get_maintainer.pl --no-l --no-r drivers/example.c
+ Developer One <dev1@example.com> (maintainer:example subsystem)
+ Developer Two <dev2@example.org> (maintainer:example subsystem)
+ Developer Three <dev3@example.com> (maintainer:example subsystem [GENERAL])
+ Developer Four <dev4@example.org> (maintainer:example subsystem [GENERAL])
+
+Here, picking the first, most specific ones, is sufficient. When the list is
+long, it is possible to produce a comma-delimited e-mail address list on a
+single line suitable for use in the To: field of a mailer like this::
+
+ $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
+ --no-git-fallback --no-substatus --no-rolestats --no-multiline \
+ --pattern-depth 1 drivers/example.c
+ dev1@example.com, dev2@example.org
+
+or this for the wider list::
+
+ $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
+ --no-git-fallback --no-substatus --no-rolestats --no-multiline \
+ drivers/example.c
+ dev1@example.com, dev2@example.org, dev3@example.com, dev4@example.org
+
+If at this point you're still facing difficulties spotting the right
+maintainers, **and only in this case**, it's possible to send your report to
+the Linux kernel security team only. Your message will be triaged, and you
+will receive instructions about whom to contact, if needed. Your message may
+equally be forwarded as-is to the relevant maintainers.
+
+Sending the report
+------------------
Reports are to be sent over e-mail exclusively. Please use a working e-mail
address, preferably the same that you want to appear in ``Reported-by`` tags
@@ -29,6 +96,7 @@ information is helpful. Any exploit code is very helpful and will not
be released without consent from the reporter unless it has already been
made public.
+The report must be sent to maintainers, with the security team in ``Cc:``.
The Linux kernel security team can be contacted by email at
<security@kernel.org>. This is a private list of security officers
who will help verify the bug report and assist developers working on a fix.
@@ -44,7 +112,9 @@ reproduction steps, and follow it with a proposed fix, all in plain text.
Markdown, HTML and RST formatted reports are particularly frowned upon since
they're quite hard to read for humans and encourage to use dedicated viewers,
sometimes online, which by definition is not acceptable for a confidential
-security report.
+security report. Note that some mailers tend to mangle formatting of plain
+text by default, please consult Documentation/process/email-clients.rst for
+more info.
Disclosure and embargoed information
------------------------------------
--
2.52.0
^ permalink raw reply related
* [PATCH v2 0/3] Documentation: clarify required info in security reports
From: Willy Tarreau @ 2026-04-03 6:20 UTC (permalink / raw)
To: greg
Cc: edumazet, rdunlap, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau
Hi Greg,
I'm sending you the doc clarifications we discussed for the process of
reporting security issues. It's cut into the 3 patches I shared this
morning on the security list (plus two typos fixed and a paragraph
asking for one single issue per report):
- one patch that reminds our need for a valid e-mail address
- one that explains to reporters how to proceed to find maintainers
addresses, hoping we won't have to do it for 90% of reports anymore
- one that enumerates basic requirements for every report
I think it covers the difficulties we've faced this week. As always,
we might possibly find tiny adjustments to add, but my goal would be
for such updates to be merged in time to update the public page ASAP
so that we can redirect incomplete reports in an attempt to lower the
team's current load.
Thanks!
Willy
---
v2:
- dropped quotes around a doc link and turned two relative doc links
to absolute ones (thanks Randy).
---
Willy Tarreau (3):
Documentation: minor updates to the security contacts
Documentation: explain how to find maintainers addresses for security
reports
Documentation: clarify the mandatory and desirable info for security
reports
Documentation/process/security-bugs.rst | 147 +++++++++++++++++++++---
1 file changed, 132 insertions(+), 15 deletions(-)
--
2.52.0
^ permalink raw reply
* [PATCH v2 1/3] Documentation: minor updates to the security contacts
From: Willy Tarreau @ 2026-04-03 6:20 UTC (permalink / raw)
To: greg
Cc: edumazet, rdunlap, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau
In-Reply-To: <20260403062018.31080-1-w@1wt.eu>
This clarifies the fact that the bug reporters must use a valid
e-mail address to send their report, and that the security team
assists developers working on a fix but doesn't always produce
fixes on its own.
Cc: Eric Dumazet <edumazet@google.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/process/security-bugs.rst | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index c0cf93e11565..da7937fd59df 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -8,6 +8,10 @@ like to know when a security bug is found so that it can be fixed and
disclosed as quickly as possible. Please report security bugs to the
Linux kernel security team.
+Reports are to be sent over e-mail exclusively. Please use a working e-mail
+address, preferably the same that you want to appear in ``Reported-by`` tags
+if any. If unsure, send your report to yourself first.
+
The security team and maintainers almost always require additional
information beyond what was initially provided in a report and rely on
active and efficient collaboration with the reporter to perform further
@@ -27,11 +31,9 @@ made public.
The Linux kernel security team can be contacted by email at
<security@kernel.org>. This is a private list of security officers
-who will help verify the bug report and develop and release a fix.
-If you already have a fix, please include it with your report, as
-that can speed up the process considerably. It is possible that the
-security team will bring in extra help from area maintainers to
-understand and fix the security vulnerability.
+who will help verify the bug report and assist developers working on a fix.
+It is possible that the security team will bring in extra help from area
+maintainers to understand and fix the security vulnerability.
Please send **plain text** emails without attachments where possible.
It is much harder to have a context-quoted discussion about a complex
--
2.52.0
^ permalink raw reply related
* Re: [PATCH 3/3] Documentation: clarify the mandatory and desirable info for security reports
From: Willy Tarreau @ 2026-04-02 19:20 UTC (permalink / raw)
To: Randy Dunlap
Cc: greg, edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <d26e37d4-0a29-4aaf-9034-3e1cc91bc6ce@infradead.org>
On Thu, Apr 02, 2026 at 12:17:38PM -0700, Randy Dunlap wrote:
>
>
> On 4/2/26 12:03 PM, Willy Tarreau wrote:
> > Hi Randy,
> >
> > On Thu, Apr 02, 2026 at 11:50:00AM -0700, Randy Dunlap wrote:
> >>
> >> On 4/2/26 11:26 AM, Willy Tarreau wrote:
> >>> A significant part of the effort of the security team consists in begging
> >>> reporters for patch proposals, or asking them to provide them in regular
> >>> format, and most of the time they're willing to provide this, they just
> >>> didn't know that it would help. So let's add a section detailing the
> >>> required and desirable contents in a security report to help reporters
> >>> write more actionable reports which do not require round trips.
> >>>
> >>> Cc: Eric Dumazet <edumazet@google.com>
> >>> Cc: Greg KH <greg@kroah.com>
> >>> Signed-off-by: Willy Tarreau <w@1wt.eu>
> >>> ---
> >>> Documentation/process/security-bugs.rst | 66 ++++++++++++++++++++++---
> >>> 1 file changed, 59 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> >>> index 6937fa9fba5a..b243ac24eb12 100644
> >>> --- a/Documentation/process/security-bugs.rst
> >>> +++ b/Documentation/process/security-bugs.rst
> >>> @@ -7,6 +7,65 @@ Linux kernel developers take security very seriously. As such, we'd
> >>> like to know when a security bug is found so that it can be fixed and
> >>> disclosed as quickly as possible.
> >>>
> >>> +Preparing your report
> >>> +---------------------
> >>> +
> >>> +Like with any bug report, a security bug report requires a lot of analysis work
> >>> +from the developers, so the more information you can share about the issue, the
> >>> +better. Please review the procedure outlined in
> >>> +'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
> >>
> >> Drop the single quote marks.
> >
> > I just moved this part as-is, and I've been extremely hesitant to change
> > formatting as I can't easily check the validity of the output.
> >
> >>> +information is helpful. The following information are absolutely necessary in
> >>> +**any** security bug report:
> >>> +
> >>> + * **affected kernel version range**: with no version indication, your report
> >>> + will not be processed. A significant part of reports are for bugs that
> >>> + have already been fixed, so it is extremely important that vulnerabilities
> >>> + are verified on recent versions (development tree or latest stable
> >>> + version), at least by verifying that the code has not changed since the
> >>> + version where it was detected.
> >>> +
> >>> + * **description of the problem**: a detailed description of the problem, with
> >>> + traces showing its manifestation, and why you consider that the observed
> >>> + behavior as a problem in the kernel, is necessary.
> >>> +
> >>> + * **reproducer**: developers will need to be able to reproduce the problem to
> >>> + consider a fix as effective. This includes both a way to trigger the issue
> >>> + and a way to confirm it happens. A reproducer with low complexity
> >>> + dependencies will be needed (source code, shell script, sequence of
> >>> + instructions, file-system image etc). Binary-only executables are not
> >>> + accepted. Working exploits are extremely helpful and will not be released
> >>> + without consent from the reporter, unless they are already public. By
> >>> + definition if an issue cannot be reproduced, it is not exploitable, thus it
> >>> + is not a security bug.
> >>> +
> >>> + * **conditions**: if the bug depends on certain configuration options,
> >>> + sysctls, permissions, timing, code modifications etc, these should be
> >>> + indicated.
> >>> +
> >>> +In addition, the following information are highly desirable:
> >>> +
> >>> + * **suspected location of the bug**: the file names and functions where the
> >>> + bug is suspected to be present are very important, at least to help forward
> >>> + the report to the appropriate maintainers. When not possible (for example,
> >>> + "system freezes each time I run this command"), the security team will help
> >>> + identify the source of the bug.
> >>> +
> >>> + * **a proposed fix**: bug reporters who have analyzed the cause of a bug in
> >>> + the source code almost always have an accurate idea on how to fix it,
> >>> + because they spent a long time studying it and its implications. Proposing
> >>> + a tested fix will save maintainers a lot of time, even if the fix ends up
> >>> + not being the right one, because it helps understand the bug. When
> >>> + proposing a tested fix, please always format it in a way that can be
> >>> + immediately merged (see :doc:`regular patch submission
> >>> + <../process/submitting-patches>`). This will save some back-and-forth
> >>
> >> Hm, I don't see anything in submitting-patches.rst called "regular patch submission".
> >> Is it in some other patch?
> >
> > Not sure what you mean. Is this supposed to be a sub-section and not just a
> > title ? On https://www.kernel.org/doc/html/latest/process/security-bugs.html
> > it appears as the title. This one was already present in the same document
> > and was moved there without a change.
>
> I see. Sorry for the noise.
No worries, I appreciate your help, the format is not trivial and mistakes
are easy!
Thanks,
Willy
^ permalink raw reply
* Re: [PATCH 3/3] Documentation: clarify the mandatory and desirable info for security reports
From: Randy Dunlap @ 2026-04-02 19:17 UTC (permalink / raw)
To: Willy Tarreau
Cc: greg, edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <ac69iG5fihUd82yH@1wt.eu>
On 4/2/26 12:03 PM, Willy Tarreau wrote:
> Hi Randy,
>
> On Thu, Apr 02, 2026 at 11:50:00AM -0700, Randy Dunlap wrote:
>>
>> On 4/2/26 11:26 AM, Willy Tarreau wrote:
>>> A significant part of the effort of the security team consists in begging
>>> reporters for patch proposals, or asking them to provide them in regular
>>> format, and most of the time they're willing to provide this, they just
>>> didn't know that it would help. So let's add a section detailing the
>>> required and desirable contents in a security report to help reporters
>>> write more actionable reports which do not require round trips.
>>>
>>> Cc: Eric Dumazet <edumazet@google.com>
>>> Cc: Greg KH <greg@kroah.com>
>>> Signed-off-by: Willy Tarreau <w@1wt.eu>
>>> ---
>>> Documentation/process/security-bugs.rst | 66 ++++++++++++++++++++++---
>>> 1 file changed, 59 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
>>> index 6937fa9fba5a..b243ac24eb12 100644
>>> --- a/Documentation/process/security-bugs.rst
>>> +++ b/Documentation/process/security-bugs.rst
>>> @@ -7,6 +7,65 @@ Linux kernel developers take security very seriously. As such, we'd
>>> like to know when a security bug is found so that it can be fixed and
>>> disclosed as quickly as possible.
>>>
>>> +Preparing your report
>>> +---------------------
>>> +
>>> +Like with any bug report, a security bug report requires a lot of analysis work
>>> +from the developers, so the more information you can share about the issue, the
>>> +better. Please review the procedure outlined in
>>> +'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
>>
>> Drop the single quote marks.
>
> I just moved this part as-is, and I've been extremely hesitant to change
> formatting as I can't easily check the validity of the output.
>
>>> +information is helpful. The following information are absolutely necessary in
>>> +**any** security bug report:
>>> +
>>> + * **affected kernel version range**: with no version indication, your report
>>> + will not be processed. A significant part of reports are for bugs that
>>> + have already been fixed, so it is extremely important that vulnerabilities
>>> + are verified on recent versions (development tree or latest stable
>>> + version), at least by verifying that the code has not changed since the
>>> + version where it was detected.
>>> +
>>> + * **description of the problem**: a detailed description of the problem, with
>>> + traces showing its manifestation, and why you consider that the observed
>>> + behavior as a problem in the kernel, is necessary.
>>> +
>>> + * **reproducer**: developers will need to be able to reproduce the problem to
>>> + consider a fix as effective. This includes both a way to trigger the issue
>>> + and a way to confirm it happens. A reproducer with low complexity
>>> + dependencies will be needed (source code, shell script, sequence of
>>> + instructions, file-system image etc). Binary-only executables are not
>>> + accepted. Working exploits are extremely helpful and will not be released
>>> + without consent from the reporter, unless they are already public. By
>>> + definition if an issue cannot be reproduced, it is not exploitable, thus it
>>> + is not a security bug.
>>> +
>>> + * **conditions**: if the bug depends on certain configuration options,
>>> + sysctls, permissions, timing, code modifications etc, these should be
>>> + indicated.
>>> +
>>> +In addition, the following information are highly desirable:
>>> +
>>> + * **suspected location of the bug**: the file names and functions where the
>>> + bug is suspected to be present are very important, at least to help forward
>>> + the report to the appropriate maintainers. When not possible (for example,
>>> + "system freezes each time I run this command"), the security team will help
>>> + identify the source of the bug.
>>> +
>>> + * **a proposed fix**: bug reporters who have analyzed the cause of a bug in
>>> + the source code almost always have an accurate idea on how to fix it,
>>> + because they spent a long time studying it and its implications. Proposing
>>> + a tested fix will save maintainers a lot of time, even if the fix ends up
>>> + not being the right one, because it helps understand the bug. When
>>> + proposing a tested fix, please always format it in a way that can be
>>> + immediately merged (see :doc:`regular patch submission
>>> + <../process/submitting-patches>`). This will save some back-and-forth
>>
>> Hm, I don't see anything in submitting-patches.rst called "regular patch submission".
>> Is it in some other patch?
>
> Not sure what you mean. Is this supposed to be a sub-section and not just a
> title ? On https://www.kernel.org/doc/html/latest/process/security-bugs.html
> it appears as the title. This one was already present in the same document
> and was moved there without a change.
I see. Sorry for the noise.
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: explain how to find maintainers addresses for security reports
From: Willy Tarreau @ 2026-04-02 19:05 UTC (permalink / raw)
To: Randy Dunlap
Cc: greg, edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <e9f0bbe9-fbff-45c8-af99-4c66982bd2cd@infradead.org>
On Thu, Apr 02, 2026 at 11:42:51AM -0700, Randy Dunlap wrote:
>
>
> On 4/2/26 11:26 AM, Willy Tarreau wrote:
> > These days, 80% of the work done by the security team consists in
> > locating the affected subsystem in a report, running get_maintainers on
> > it, forwarding the report to these persons and responding to the reporter
> > with them in Cc. This is a huge and unneeded overhead that we must try to
> > lower for a better overall efficiency. This patch adds a complete section
> > explaining how to figure the list of recipients to send the report to.
> >
> > Cc: Eric Dumazet <edumazet@google.com>
> > Cc: Greg KH <greg@kroah.com>
> > Signed-off-by: Willy Tarreau <w@1wt.eu>
> > ---
> > Documentation/process/security-bugs.rst | 76 ++++++++++++++++++++++++-
> > 1 file changed, 73 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> > index da7937fd59df..6937fa9fba5a 100644
> > --- a/Documentation/process/security-bugs.rst
> > +++ b/Documentation/process/security-bugs.rst
>
>
> > Markdown, HTML and RST formatted reports are particularly frowned upon since
> > they're quite hard to read for humans and encourage to use dedicated viewers,
> > sometimes online, which by definition is not acceptable for a confidential
> > -security report.
> > +security report. Note that some mailers tend to mangle formatting of plain
> > +text by default, please consult :doc:`the email client howto
> > +<../process/email-clients>` for more info.
>
> Just use the file name and let automarkup do its job:
>
> text by default; please consult Documentation/process/email-clients.rst
> for more information.
>
> It's also more convenient for text readers that way.
If that's supposed to work, I'm indeed all for it! I must confess that
I have not even understood the reason for "../process" when coming from
the same directory, but I just picked that from existing entries.
Thanks for your feedback, much appreciated!
Willy
^ permalink raw reply
* Re: [PATCH 3/3] Documentation: clarify the mandatory and desirable info for security reports
From: Willy Tarreau @ 2026-04-02 19:03 UTC (permalink / raw)
To: Randy Dunlap
Cc: greg, edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <18127458-1951-4b44-bcbb-a5747a3b4b6b@infradead.org>
Hi Randy,
On Thu, Apr 02, 2026 at 11:50:00AM -0700, Randy Dunlap wrote:
>
> On 4/2/26 11:26 AM, Willy Tarreau wrote:
> > A significant part of the effort of the security team consists in begging
> > reporters for patch proposals, or asking them to provide them in regular
> > format, and most of the time they're willing to provide this, they just
> > didn't know that it would help. So let's add a section detailing the
> > required and desirable contents in a security report to help reporters
> > write more actionable reports which do not require round trips.
> >
> > Cc: Eric Dumazet <edumazet@google.com>
> > Cc: Greg KH <greg@kroah.com>
> > Signed-off-by: Willy Tarreau <w@1wt.eu>
> > ---
> > Documentation/process/security-bugs.rst | 66 ++++++++++++++++++++++---
> > 1 file changed, 59 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> > index 6937fa9fba5a..b243ac24eb12 100644
> > --- a/Documentation/process/security-bugs.rst
> > +++ b/Documentation/process/security-bugs.rst
> > @@ -7,6 +7,65 @@ Linux kernel developers take security very seriously. As such, we'd
> > like to know when a security bug is found so that it can be fixed and
> > disclosed as quickly as possible.
> >
> > +Preparing your report
> > +---------------------
> > +
> > +Like with any bug report, a security bug report requires a lot of analysis work
> > +from the developers, so the more information you can share about the issue, the
> > +better. Please review the procedure outlined in
> > +'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
>
> Drop the single quote marks.
I just moved this part as-is, and I've been extremely hesitant to change
formatting as I can't easily check the validity of the output.
> > +information is helpful. The following information are absolutely necessary in
> > +**any** security bug report:
> > +
> > + * **affected kernel version range**: with no version indication, your report
> > + will not be processed. A significant part of reports are for bugs that
> > + have already been fixed, so it is extremely important that vulnerabilities
> > + are verified on recent versions (development tree or latest stable
> > + version), at least by verifying that the code has not changed since the
> > + version where it was detected.
> > +
> > + * **description of the problem**: a detailed description of the problem, with
> > + traces showing its manifestation, and why you consider that the observed
> > + behavior as a problem in the kernel, is necessary.
> > +
> > + * **reproducer**: developers will need to be able to reproduce the problem to
> > + consider a fix as effective. This includes both a way to trigger the issue
> > + and a way to confirm it happens. A reproducer with low complexity
> > + dependencies will be needed (source code, shell script, sequence of
> > + instructions, file-system image etc). Binary-only executables are not
> > + accepted. Working exploits are extremely helpful and will not be released
> > + without consent from the reporter, unless they are already public. By
> > + definition if an issue cannot be reproduced, it is not exploitable, thus it
> > + is not a security bug.
> > +
> > + * **conditions**: if the bug depends on certain configuration options,
> > + sysctls, permissions, timing, code modifications etc, these should be
> > + indicated.
> > +
> > +In addition, the following information are highly desirable:
> > +
> > + * **suspected location of the bug**: the file names and functions where the
> > + bug is suspected to be present are very important, at least to help forward
> > + the report to the appropriate maintainers. When not possible (for example,
> > + "system freezes each time I run this command"), the security team will help
> > + identify the source of the bug.
> > +
> > + * **a proposed fix**: bug reporters who have analyzed the cause of a bug in
> > + the source code almost always have an accurate idea on how to fix it,
> > + because they spent a long time studying it and its implications. Proposing
> > + a tested fix will save maintainers a lot of time, even if the fix ends up
> > + not being the right one, because it helps understand the bug. When
> > + proposing a tested fix, please always format it in a way that can be
> > + immediately merged (see :doc:`regular patch submission
> > + <../process/submitting-patches>`). This will save some back-and-forth
>
> Hm, I don't see anything in submitting-patches.rst called "regular patch submission".
> Is it in some other patch?
Not sure what you mean. Is this supposed to be a sub-section and not just a
title ? On https://www.kernel.org/doc/html/latest/process/security-bugs.html
it appears as the title. This one was already present in the same document
and was moved there without a change.
Thanks a lot for your help!
Willy
^ permalink raw reply
* Re: [PATCH 3/3] Documentation: clarify the mandatory and desirable info for security reports
From: Randy Dunlap @ 2026-04-02 18:50 UTC (permalink / raw)
To: Willy Tarreau, greg
Cc: edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <20260402182655.8636-4-w@1wt.eu>
On 4/2/26 11:26 AM, Willy Tarreau wrote:
> A significant part of the effort of the security team consists in begging
> reporters for patch proposals, or asking them to provide them in regular
> format, and most of the time they're willing to provide this, they just
> didn't know that it would help. So let's add a section detailing the
> required and desirable contents in a security report to help reporters
> write more actionable reports which do not require round trips.
>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Greg KH <greg@kroah.com>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> Documentation/process/security-bugs.rst | 66 ++++++++++++++++++++++---
> 1 file changed, 59 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> index 6937fa9fba5a..b243ac24eb12 100644
> --- a/Documentation/process/security-bugs.rst
> +++ b/Documentation/process/security-bugs.rst
> @@ -7,6 +7,65 @@ Linux kernel developers take security very seriously. As such, we'd
> like to know when a security bug is found so that it can be fixed and
> disclosed as quickly as possible.
>
> +Preparing your report
> +---------------------
> +
> +Like with any bug report, a security bug report requires a lot of analysis work
> +from the developers, so the more information you can share about the issue, the
> +better. Please review the procedure outlined in
> +'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
Drop the single quote marks.
> +information is helpful. The following information are absolutely necessary in
> +**any** security bug report:
> +
> + * **affected kernel version range**: with no version indication, your report
> + will not be processed. A significant part of reports are for bugs that
> + have already been fixed, so it is extremely important that vulnerabilities
> + are verified on recent versions (development tree or latest stable
> + version), at least by verifying that the code has not changed since the
> + version where it was detected.
> +
> + * **description of the problem**: a detailed description of the problem, with
> + traces showing its manifestation, and why you consider that the observed
> + behavior as a problem in the kernel, is necessary.
> +
> + * **reproducer**: developers will need to be able to reproduce the problem to
> + consider a fix as effective. This includes both a way to trigger the issue
> + and a way to confirm it happens. A reproducer with low complexity
> + dependencies will be needed (source code, shell script, sequence of
> + instructions, file-system image etc). Binary-only executables are not
> + accepted. Working exploits are extremely helpful and will not be released
> + without consent from the reporter, unless they are already public. By
> + definition if an issue cannot be reproduced, it is not exploitable, thus it
> + is not a security bug.
> +
> + * **conditions**: if the bug depends on certain configuration options,
> + sysctls, permissions, timing, code modifications etc, these should be
> + indicated.
> +
> +In addition, the following information are highly desirable:
> +
> + * **suspected location of the bug**: the file names and functions where the
> + bug is suspected to be present are very important, at least to help forward
> + the report to the appropriate maintainers. When not possible (for example,
> + "system freezes each time I run this command"), the security team will help
> + identify the source of the bug.
> +
> + * **a proposed fix**: bug reporters who have analyzed the cause of a bug in
> + the source code almost always have an accurate idea on how to fix it,
> + because they spent a long time studying it and its implications. Proposing
> + a tested fix will save maintainers a lot of time, even if the fix ends up
> + not being the right one, because it helps understand the bug. When
> + proposing a tested fix, please always format it in a way that can be
> + immediately merged (see :doc:`regular patch submission
> + <../process/submitting-patches>`). This will save some back-and-forth
Hm, I don't see anything in submitting-patches.rst called "regular patch submission".
Is it in some other patch?
> + exchanges if it is accepted, and you will be credited for finding and
> + fixing this issue. Note that in this case only a ``Signed-off-by:`` tag is
> + needed, without ``Reported-by:` when the reporter and author are the same.
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: explain how to find maintainers addresses for security reports
From: Randy Dunlap @ 2026-04-02 18:42 UTC (permalink / raw)
To: Willy Tarreau, greg
Cc: edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <20260402182655.8636-3-w@1wt.eu>
On 4/2/26 11:26 AM, Willy Tarreau wrote:
> These days, 80% of the work done by the security team consists in
> locating the affected subsystem in a report, running get_maintainers on
> it, forwarding the report to these persons and responding to the reporter
> with them in Cc. This is a huge and unneeded overhead that we must try to
> lower for a better overall efficiency. This patch adds a complete section
> explaining how to figure the list of recipients to send the report to.
>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Greg KH <greg@kroah.com>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> Documentation/process/security-bugs.rst | 76 ++++++++++++++++++++++++-
> 1 file changed, 73 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> index da7937fd59df..6937fa9fba5a 100644
> --- a/Documentation/process/security-bugs.rst
> +++ b/Documentation/process/security-bugs.rst
> Markdown, HTML and RST formatted reports are particularly frowned upon since
> they're quite hard to read for humans and encourage to use dedicated viewers,
> sometimes online, which by definition is not acceptable for a confidential
> -security report.
> +security report. Note that some mailers tend to mangle formatting of plain
> +text by default, please consult :doc:`the email client howto
> +<../process/email-clients>` for more info.
Just use the file name and let automarkup do its job:
text by default; please consult Documentation/process/email-clients.rst
for more information.
It's also more convenient for text readers that way.
>
> Disclosure and embargoed information
> ------------------------------------
--
~Randy
^ permalink raw reply
* [PATCH 0/3] Documentation: clarify required info in security reports
From: Willy Tarreau @ 2026-04-02 18:26 UTC (permalink / raw)
To: greg
Cc: edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau
Hi Greg,
I'm sending you the doc clarifications we discussed for the process of
reporting security issues. It's cut into the 3 patches I shared this
morning on the security list (plus two typos fixed and a paragraph
asking for one single issue per report):
- one patch that reminds our need for a valid e-mail address
- one that explains to reporters how to proceed to find maintainers
addresses, hoping we won't have to do it for 90% of reports anymore
- one that enumerates basic requirements for every report
I think it covers the difficulties we've faced this week. As always,
we might possibly find tiny adjustments to add, but my goal would be
for such updates to be merged in time to update the public page ASAP
so that we can redirect incomplete reports in an attempt to lower the
team's current load.
Thanks!
Willy
---
Willy Tarreau (3):
Documentation: minor updates to the security contacts
Documentation: explain how to find maintainers addresses for security
reports
Documentation: clarify the mandatory and desirable info for security
reports
Documentation/process/security-bugs.rst | 147 +++++++++++++++++++++---
1 file changed, 132 insertions(+), 15 deletions(-)
--
2.52.0
^ permalink raw reply
* [PATCH 3/3] Documentation: clarify the mandatory and desirable info for security reports
From: Willy Tarreau @ 2026-04-02 18:26 UTC (permalink / raw)
To: greg
Cc: edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau
In-Reply-To: <20260402182655.8636-1-w@1wt.eu>
A significant part of the effort of the security team consists in begging
reporters for patch proposals, or asking them to provide them in regular
format, and most of the time they're willing to provide this, they just
didn't know that it would help. So let's add a section detailing the
required and desirable contents in a security report to help reporters
write more actionable reports which do not require round trips.
Cc: Eric Dumazet <edumazet@google.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/process/security-bugs.rst | 66 ++++++++++++++++++++++---
1 file changed, 59 insertions(+), 7 deletions(-)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 6937fa9fba5a..b243ac24eb12 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -7,6 +7,65 @@ Linux kernel developers take security very seriously. As such, we'd
like to know when a security bug is found so that it can be fixed and
disclosed as quickly as possible.
+Preparing your report
+---------------------
+
+Like with any bug report, a security bug report requires a lot of analysis work
+from the developers, so the more information you can share about the issue, the
+better. Please review the procedure outlined in
+'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
+information is helpful. The following information are absolutely necessary in
+**any** security bug report:
+
+ * **affected kernel version range**: with no version indication, your report
+ will not be processed. A significant part of reports are for bugs that
+ have already been fixed, so it is extremely important that vulnerabilities
+ are verified on recent versions (development tree or latest stable
+ version), at least by verifying that the code has not changed since the
+ version where it was detected.
+
+ * **description of the problem**: a detailed description of the problem, with
+ traces showing its manifestation, and why you consider that the observed
+ behavior as a problem in the kernel, is necessary.
+
+ * **reproducer**: developers will need to be able to reproduce the problem to
+ consider a fix as effective. This includes both a way to trigger the issue
+ and a way to confirm it happens. A reproducer with low complexity
+ dependencies will be needed (source code, shell script, sequence of
+ instructions, file-system image etc). Binary-only executables are not
+ accepted. Working exploits are extremely helpful and will not be released
+ without consent from the reporter, unless they are already public. By
+ definition if an issue cannot be reproduced, it is not exploitable, thus it
+ is not a security bug.
+
+ * **conditions**: if the bug depends on certain configuration options,
+ sysctls, permissions, timing, code modifications etc, these should be
+ indicated.
+
+In addition, the following information are highly desirable:
+
+ * **suspected location of the bug**: the file names and functions where the
+ bug is suspected to be present are very important, at least to help forward
+ the report to the appropriate maintainers. When not possible (for example,
+ "system freezes each time I run this command"), the security team will help
+ identify the source of the bug.
+
+ * **a proposed fix**: bug reporters who have analyzed the cause of a bug in
+ the source code almost always have an accurate idea on how to fix it,
+ because they spent a long time studying it and its implications. Proposing
+ a tested fix will save maintainers a lot of time, even if the fix ends up
+ not being the right one, because it helps understand the bug. When
+ proposing a tested fix, please always format it in a way that can be
+ immediately merged (see :doc:`regular patch submission
+ <../process/submitting-patches>`). This will save some back-and-forth
+ exchanges if it is accepted, and you will be credited for finding and
+ fixing this issue. Note that in this case only a ``Signed-off-by:`` tag is
+ needed, without ``Reported-by:` when the reporter and author are the same.
+
+ * **mitigations**: very often during a bug analysis, some ways of mitigating
+ the issue appear. It is useful to share them, as they can be helpful to
+ keep end users protected during the time it takes them to apply the fix.
+
Identifying contacts
--------------------
@@ -89,13 +148,6 @@ run additional tests. Reports where the reporter does not respond promptly
or cannot effectively discuss their findings may be abandoned if the
communication does not quickly improve.
-As it is with any bug, the more information provided the easier it
-will be to diagnose and fix. Please review the procedure outlined in
-'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
-information is helpful. Any exploit code is very helpful and will not
-be released without consent from the reporter unless it has already been
-made public.
-
The report must be sent to maintainers, with the security team in ``Cc:``.
The Linux kernel security team can be contacted by email at
<security@kernel.org>. This is a private list of security officers
--
2.52.0
^ permalink raw reply related
* [PATCH 2/3] Documentation: explain how to find maintainers addresses for security reports
From: Willy Tarreau @ 2026-04-02 18:26 UTC (permalink / raw)
To: greg
Cc: edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau
In-Reply-To: <20260402182655.8636-1-w@1wt.eu>
These days, 80% of the work done by the security team consists in
locating the affected subsystem in a report, running get_maintainers on
it, forwarding the report to these persons and responding to the reporter
with them in Cc. This is a huge and unneeded overhead that we must try to
lower for a better overall efficiency. This patch adds a complete section
explaining how to figure the list of recipients to send the report to.
Cc: Eric Dumazet <edumazet@google.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/process/security-bugs.rst | 76 ++++++++++++++++++++++++-
1 file changed, 73 insertions(+), 3 deletions(-)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index da7937fd59df..6937fa9fba5a 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -5,8 +5,75 @@ Security bugs
Linux kernel developers take security very seriously. As such, we'd
like to know when a security bug is found so that it can be fixed and
-disclosed as quickly as possible. Please report security bugs to the
-Linux kernel security team.
+disclosed as quickly as possible.
+
+Identifying contacts
+--------------------
+
+The most effective way to report a security bug is to send it directly to the
+affected subsystem's maintainers and Cc: the Linux kernel security team. Do
+not send it to a public list at this stage, unless you have good reasons to
+consider the issue as being public or trivial to discover (e.g. result of a
+widely available automated vulnerability scanning tool that can be repeated by
+anyone).
+
+If you're sending a report for issues affecting multiple parts in the kernel,
+even if they're fairly similar issues, please send individual messages (think
+that maintainers will not all work on the issues at the same time). The only
+exception is when an issue concerns closely related parts maintained by the
+exact same subset of maintainers, and these parts are expected to be fixed all
+at once by the same commit, then it may be acceptable to report them at once.
+
+One difficulty for most first-time reporters is to figure the right list of
+recipients to send a report to. In the Linux kernel, all official maintainers
+are trusted, so the consequences of accidentally including the wrong maintainer
+are essentially a bit more noise for that person, i.e. nothing dramatic. As
+such, a suitable method to figure the list of maintainers (which kernel
+security officers use) is to rely on the get_maintainers.pl script, tuned to
+only report maintainers. This script, when passed a file name, will look for
+its path in the MAINTAINERS file to figure a hierarchical list of relevant
+maintainers. Calling it a first time with the finest level of filtering will
+most of the time return a short list of this specific file's maintainers::
+
+ $ ./scripts/get_maintainer.pl --no-l --no-r --pattern-depth 1 \
+ drivers/example.c
+ Developer One <dev1@example.com> (maintainer:example driver)
+ Developer Two <dev2@example.org> (maintainer:example driver)
+
+These two maintainers should then receive the message. If the command does not
+return anything, it means the affected file is part of a wider subsystem, so we
+should be less specific::
+
+ $ ./scripts/get_maintainer.pl --no-l --no-r drivers/example.c
+ Developer One <dev1@example.com> (maintainer:example subsystem)
+ Developer Two <dev2@example.org> (maintainer:example subsystem)
+ Developer Three <dev3@example.com> (maintainer:example subsystem [GENERAL])
+ Developer Four <dev4@example.org> (maintainer:example subsystem [GENERAL])
+
+Here, picking the first, most specific ones, is sufficient. When the list is
+long, it is possible to produce a comma-delimited e-mail address list on a
+single line suitable for use in the To: field of a mailer like this::
+
+ $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
+ --no-git-fallback --no-substatus --no-rolestats --no-multiline \
+ --pattern-depth 1 drivers/example.c
+ dev1@example.com, dev2@example.org
+
+or this for the wider list::
+
+ $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
+ --no-git-fallback --no-substatus --no-rolestats --no-multiline \
+ drivers/example.c
+ dev1@example.com, dev2@example.org, dev3@example.com, dev4@example.org
+
+If at this point you're still facing difficulties spotting the right
+maintainers, **and only in this case**, it's possible to send your report to
+the Linux kernel security team only. Your message will be triaged, and you
+will receive instructions about whom to contact, if needed. Your message may
+equally be forwarded as-is to the relevant maintainers.
+
+Sending the report
+------------------
Reports are to be sent over e-mail exclusively. Please use a working e-mail
address, preferably the same that you want to appear in ``Reported-by`` tags
@@ -29,6 +96,7 @@ information is helpful. Any exploit code is very helpful and will not
be released without consent from the reporter unless it has already been
made public.
+The report must be sent to maintainers, with the security team in ``Cc:``.
The Linux kernel security team can be contacted by email at
<security@kernel.org>. This is a private list of security officers
who will help verify the bug report and assist developers working on a fix.
@@ -44,7 +112,9 @@ reproduction steps, and follow it with a proposed fix, all in plain text.
Markdown, HTML and RST formatted reports are particularly frowned upon since
they're quite hard to read for humans and encourage to use dedicated viewers,
sometimes online, which by definition is not acceptable for a confidential
-security report.
+security report. Note that some mailers tend to mangle formatting of plain
+text by default, please consult :doc:`the email client howto
+<../process/email-clients>` for more info.
Disclosure and embargoed information
------------------------------------
--
2.52.0
^ permalink raw reply related
* [PATCH 1/3] Documentation: minor updates to the security contacts
From: Willy Tarreau @ 2026-04-02 18:26 UTC (permalink / raw)
To: greg
Cc: edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau
In-Reply-To: <20260402182655.8636-1-w@1wt.eu>
This clarifies the fact that the bug reporters must use a valid
e-mail address to send their report, and that the security team
assists developers working on a fix but doesn't always produce
fixes on its own.
Cc: Eric Dumazet <edumazet@google.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/process/security-bugs.rst | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index c0cf93e11565..da7937fd59df 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -8,6 +8,10 @@ like to know when a security bug is found so that it can be fixed and
disclosed as quickly as possible. Please report security bugs to the
Linux kernel security team.
+Reports are to be sent over e-mail exclusively. Please use a working e-mail
+address, preferably the same that you want to appear in ``Reported-by`` tags
+if any. If unsure, send your report to yourself first.
+
The security team and maintainers almost always require additional
information beyond what was initially provided in a report and rely on
active and efficient collaboration with the reporter to perform further
@@ -27,11 +31,9 @@ made public.
The Linux kernel security team can be contacted by email at
<security@kernel.org>. This is a private list of security officers
-who will help verify the bug report and develop and release a fix.
-If you already have a fix, please include it with your report, as
-that can speed up the process considerably. It is possible that the
-security team will bring in extra help from area maintainers to
-understand and fix the security vulnerability.
+who will help verify the bug report and assist developers working on a fix.
+It is possible that the security team will bring in extra help from area
+maintainers to understand and fix the security vulnerability.
Please send **plain text** emails without attachments where possible.
It is much harder to have a context-quoted discussion about a complex
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] Doc: process: Added two important books for Linux Kernel programming and development
From: Jonathan Corbet @ 2026-03-30 16:53 UTC (permalink / raw)
To: Bhaskar Chowdhury, skhan, workflows, linux-doc, linux-kernel
Cc: Bhaskar Chowdhury
In-Reply-To: <20260328074745.2309736-1-unixbhaskar@gmail.com>
Bhaskar Chowdhury <unixbhaskar@gmail.com> writes:
> These books are very well written and enhance the understanding of the process.
>
> Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
> ---
> Documentation/process/howto.rst | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
> index 9438e03d6f50..c5164a27fc1a 100644
> --- a/Documentation/process/howto.rst
> +++ b/Documentation/process/howto.rst
> @@ -34,7 +34,8 @@ experience, the following books are good for, if anything, reference:
> - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
> - "Practical C Programming" by Steve Oualline [O'Reilly]
> - "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
> -
> + - "Linux System Programming" by Robert Love [O'Reilly]
> + - "Linux Kernel Development" By Robert Love [Pearson]
> The kernel is written using GNU C and the GNU toolchain. While it
Adding mention of those books might well be a good thing to do, but
you're adding them in the middle of a section that is talking about C
programming specifically. It doesn't make much sense to put them there.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v5 2/2] workflows, scripts: sort ver_linux and changes.rst
From: Jonathan Corbet @ 2026-03-30 16:38 UTC (permalink / raw)
To: Manuel Ebner, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Manuel Ebner
In-Reply-To: <20260325194811.78509-2-manuelebner@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
> sort output of scripts/ver_linux alphabetically
> sort list in changes.rst alphabetically
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> ---
> Documentation/process/changes.rst | 52 ++++++++++++-------------
> scripts/ver_linux | 64 +++++++++++++++----------------
> 2 files changed, 58 insertions(+), 58 deletions(-)
Changelog is now:
docs: changes.rst and ver_linux: sort the lists
Sort the lists of tools in both scripts/ver_linux and
Documentation/process/changes.rst into alphabetical order, facilitating
comparison between the two.
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
[jc: rewrote changelog]
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
As an additional note...what would be Really Nice would be to have a
single list of tool dependencies that could be automatically used by
both files. An additional bonus would be a mode in script/ver_linux to
only report on tools that are missing or below the required version. A
guy can dream...:)
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v5 1/2] workflows, scripts: harmonize and cleanup
From: Jonathan Corbet @ 2026-03-30 16:36 UTC (permalink / raw)
To: Manuel Ebner, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Manuel Ebner
In-Reply-To: <20260325194616.78093-2-manuelebner@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
> cleanup and harmonize output of scripts/ver_linux and table in changes.rst
>
> ver_linux:
> fix path to changes.rst
> Add missing tools in ver_linux
> bash, bc, bindgen, btrfs-progs, Clang, gdb, GNU awk, GNU tar,
> GRUB, GRUB2, gtags, iptables, kmod, mcelog, mkimage, openssl,
> pahole, Python, Rust, Sphinx, squashfs-tools
>
> changes.rst:
> add reference to ./scripts/ver_linux
> needn't -> do not need to
> add gdb version 7.2 as mentioned in:
> Documentation/process/debugging/gdb-kernel-debugging.rst
> scripts/gdb/vmlinux-gdb.py
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
Applied, but the changelog now reads:
docs: changes/ver_linux: fix entries and add several tools
Some of the entries in both Documentation/process/changes.rst and
script/ver_linux were obsolete; update them to reflect the current way of
getting version information.
Many were missing altogether; add the relevant information for:
bash, bc, bindgen, btrfs-progs, Clang, gdb, GNU awk, GNU tar,
GRUB, GRUB2, gtags, iptables, kmod, mcelog, mkimage, openssl,
pahole, Python, Rust, Sphinx, squashfs-tools
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
[jc: rewrote changelog]
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
jon
^ permalink raw reply
* Re: [PATCH v5 0/2] workflow, scripts: sort changes.rst and ver_linux
From: Jonathan Corbet @ 2026-03-30 16:32 UTC (permalink / raw)
To: Manuel Ebner, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Manuel Ebner
In-Reply-To: <20260325194326.77923-2-manuelebner@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
> restructured the patch series into logical changes.
> fixed changelogs, but i'm not super content.
>
> [v4] -> [v5]:
> undo "remove (optional)" from [v4]
> merged patches with same concepts
> [PATCH v4 1/4], [PATCH v4 2/4] -> [PATCH v5 1/2]
> [PATCH v4 3/4], [PATCH v4 4/4] -> [PATCH v5 2/2]
> fix changelogs for the individual patches
OK, I have applied this series. For any future changes, though, I
really need you to work on your changelogs.
The 0/N cover letter should describe what the series as a whole does,
you didn't do that here.
For the individual patches, I have rewritten the changelogs; I'll reply
to each with what I've done.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] Documentation: Provide hints on how to debug Python GDB scripts
From: Jonathan Corbet @ 2026-03-30 16:15 UTC (permalink / raw)
To: Florian Fainelli, linux-kernel, akpm
Cc: tglx, radu, Florian Fainelli, Shuah Khan, Illia Ostapyshyn,
open list:DOCUMENTATION PROCESS, open list:DOCUMENTATION
In-Reply-To: <20260326233226.2248817-1-florian.fainelli@broadcom.com>
Florian Fainelli <florian.fainelli@broadcom.com> writes:
> By default GDB does not print a full stack of its integrated Python
> interpreter, thus making the debugging of GDB scripts more painful than
> it has to be.
>
> Suggested-by: Radu Rendec <radu@rendec.net>
> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
> ---
> Documentation/process/debugging/gdb-kernel-debugging.rst | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/process/debugging/gdb-kernel-debugging.rst b/Documentation/process/debugging/gdb-kernel-debugging.rst
> index 9475c759c722..53e225760a4d 100644
> --- a/Documentation/process/debugging/gdb-kernel-debugging.rst
> +++ b/Documentation/process/debugging/gdb-kernel-debugging.rst
> @@ -173,3 +173,12 @@ this is just a snapshot of the initial version::
>
> Detailed help can be obtained via "help <command-name>" for commands and "help
> function <function-name>" for convenience functions.
> +
> +Debugging GDB scripts
> +---------------------
> +
> +GDB does not enable a full Python backtrace which can make debugging GDB
> +scripts more difficult than necessary. The following will allow for printing a
> +full backtrace of the python environment::
> +
> + (gdb) set python print-stack full
Applied, thanks.
jon
^ permalink raw reply
* [PATCH v12 15/15] docs: Update KASAN and x86 memory map documentations
From: Maciej Wieczor-Retman @ 2026-03-30 14:34 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Jonathan Corbet, Shuah Khan, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino
Cc: m.wieczorretman, Maciej Wieczor-Retman, linux-kernel, linux-doc,
kasan-dev, workflows
In-Reply-To: <cover.1774872838.git.m.wieczorretman@pm.me>
From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Update the documentation concerning changes to x86's memory address
space and new architecture addition to KASAN's software tag-based mode.
Redo paragraphs in KASAN's documentation on hardware and software
implementation details to allow better extensibility.
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
Changelog v11:
- Split off the documentation portion of v10's patch 13.
- Apply Dave's suggestions to reformat the footer explaining alternate
ranges for KASAN shadow memory, put arch hardware implementation in a
separate paragraph and make a table to hold various implementation
details.
Documentation/arch/x86/x86_64/mm.rst | 21 +++++++++-
Documentation/dev-tools/kasan.rst | 61 ++++++++++++++++++++--------
2 files changed, 62 insertions(+), 20 deletions(-)
diff --git a/Documentation/arch/x86/x86_64/mm.rst b/Documentation/arch/x86/x86_64/mm.rst
index a6cf05d51bd8..3c78ab1afd8d 100644
--- a/Documentation/arch/x86/x86_64/mm.rst
+++ b/Documentation/arch/x86/x86_64/mm.rst
@@ -60,7 +60,7 @@ Complete virtual memory map with 4-level page tables
ffffe90000000000 | -23 TB | ffffe9ffffffffff | 1 TB | ... unused hole
ffffea0000000000 | -22 TB | ffffeaffffffffff | 1 TB | virtual memory map (vmemmap_base)
ffffeb0000000000 | -21 TB | ffffebffffffffff | 1 TB | ... unused hole
- ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory
+ ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory[1]
__________________|____________|__________________|_________|____________________________________________________________
|
| Identical layout to the 56-bit one from here on:
@@ -130,7 +130,7 @@ Complete virtual memory map with 5-level page tables
ffd2000000000000 | -11.5 PB | ffd3ffffffffffff | 0.5 PB | ... unused hole
ffd4000000000000 | -11 PB | ffd5ffffffffffff | 0.5 PB | virtual memory map (vmemmap_base)
ffd6000000000000 | -10.5 PB | ffdeffffffffffff | 2.25 PB | ... unused hole
- ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory
+ ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory[1]
__________________|____________|__________________|_________|____________________________________________________________
|
| Identical layout to the 47-bit one from here on:
@@ -178,3 +178,20 @@ correct as KASAN disables KASLR.
For both 4- and 5-level layouts, the KSTACK_ERASE_POISON value in the last 2MB
hole: ffffffffffff4111
+
+1. The range is different based on what KASAN mode is used and what paging level
+ is used:
+
+::
+
+ ============================================================================================================
+ Start addr | Offset | End addr | Size | VM area description
+ ============================================================================================================
+ | | | | 4-level paging:
+ ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory (generic mode)
+ fffff40000000000 | -8 TB | fffffbffffffffff | 8 TB | KASAN shadow memory (software tag-based mode)
+ __________________|____________|__________________|_________|_______________________________________________
+ | | | | 5-level paging:
+ ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory (generic mode)
+ ffeffc0000000000 | -6 PB | fffffbffffffffff | 4 PB | KASAN shadow memory (software tag-based mode)
+ __________________|____________|__________________|_________|_______________________________________________
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index b11c1be8dff4..d42d80e9fcf1 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -22,8 +22,8 @@ architectures, but it has significant performance and memory overheads.
Software Tag-Based KASAN or SW_TAGS KASAN, enabled with CONFIG_KASAN_SW_TAGS,
can be used for both debugging and dogfood testing, similar to userspace HWASan.
-This mode is only supported for arm64, but its moderate memory overhead allows
-using it for testing on memory-restricted devices with real workloads.
+This mode is only supported for arm64 and x86, but its moderate memory overhead
+allows using it for testing on memory-restricted devices with real workloads.
Hardware Tag-Based KASAN or HW_TAGS KASAN, enabled with CONFIG_KASAN_HW_TAGS,
is the mode intended to be used as an in-field memory bug detector or as a
@@ -346,16 +346,21 @@ Software Tag-Based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
Software Tag-Based KASAN uses a software memory tagging approach to checking
-access validity. It is currently only implemented for the arm64 architecture.
-
-Software Tag-Based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs
-to store a pointer tag in the top byte of kernel pointers. It uses shadow memory
-to store memory tags associated with each 16-byte memory cell (therefore, it
-dedicates 1/16th of the kernel memory for shadow memory).
-
-On each memory allocation, Software Tag-Based KASAN generates a random tag, tags
-the allocated memory with this tag, and embeds the same tag into the returned
-pointer.
+access validity. It is currently only implemented for the arm64 and x86
+architectures. To function, special hardware CPU features* are needed for
+repurposing space inside the kernel pointers to store pointer tags.
+
+Software Tag-Based mode uses shadow memory to store memory tags associated with
+each 16-byte memory cell (therefore, it dedicates 1/16th of the kernel memory
+for shadow memory). On each memory allocation, Software Tag-Based KASAN
+generates a random tag, tags the allocated memory with this tag, and embeds the
+same tag into the returned pointer.
+
+Two special tag values can be distinguished. A match-all pointer tag (otherwise
+called the 'kernel tag' because it's supposed to be equal to the value normally
+present in the same bits of the linear address when KASAN is disabled) -
+accesses through such pointers are not checked. Another value is also reserved
+to tag freed memory regions.
Software Tag-Based KASAN uses compile-time instrumentation to insert checks
before each memory access. These checks make sure that the tag of the memory
@@ -367,12 +372,32 @@ Software Tag-Based KASAN also has two instrumentation modes (outline, which
emits callbacks to check memory accesses; and inline, which performs the shadow
memory checks inline). With outline instrumentation mode, a bug report is
printed from the function that performs the access check. With inline
-instrumentation, a ``brk`` instruction is emitted by the compiler, and a
-dedicated ``brk`` handler is used to print bug reports.
-
-Software Tag-Based KASAN uses 0xFF as a match-all pointer tag (accesses through
-pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently
-reserved to tag freed memory regions.
+instrumentation, the compiler emits a specific arch-dependent instruction with a
+dedicated handler to print bug reports.
+
+Architecture specific details:
+
+::
+
+ +-----------------------+--------+---------------------+
+ | detail \ architecture | arm64 | x86 |
+ +=======================+========+=====================+
+ | Hardware feature | TBI | LAM |
+ +-----------------------+--------+---------------------+
+ | Kernel tag | 0xFF | 0x0F |
+ +-----------------------+--------+---------------------+
+ | Freed memory tag | 0xFE | 0x0E |
+ +-----------------------+--------+---------------------+
+ | Tag width | 8 bits | 4 bits |
+ +-----------------------+--------+---------------------+
+ | Inline instruction | brk | no compiler support |
+ +-----------------------+--------+---------------------+
+
+* Different architectures implement different hardware features to mask and
+ repurpose linear address bits. arm64 utilizes Top Byte Ignore (TBI) to mask
+ out and allow storing tags in the top byte of the pointer. x86 uses Linear
+ Address Masking (LAM) to store tags in the four bits of the kernel pointer's
+ top byte.
Hardware Tag-Based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
--
2.53.0
^ permalink raw reply related
* [PATCH v12 01/15] kasan: sw_tags: Use arithmetic shift for shadow computation
From: Maciej Wieczor-Retman @ 2026-03-30 14:33 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Jonathan Corbet, Shuah Khan,
Andrey Ryabinin, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, Vincenzo Frascino, Andrew Morton, Jan Kiszka,
Kieran Bingham, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt
Cc: m.wieczorretman, Samuel Holland, Maciej Wieczor-Retman,
linux-arm-kernel, linux-doc, linux-kernel, kasan-dev, workflows,
linux-mm, llvm
In-Reply-To: <cover.1774872838.git.m.wieczorretman@pm.me>
From: Samuel Holland <samuel.holland@sifive.com>
Currently, kasan_mem_to_shadow() uses a logical right shift, which turns
canonical kernel addresses into non-canonical addresses by clearing the
high KASAN_SHADOW_SCALE_SHIFT bits. The value of KASAN_SHADOW_OFFSET is
then chosen so that the addition results in a canonical address for the
shadow memory.
For KASAN_GENERIC, this shift/add combination is ABI with the compiler,
because KASAN_SHADOW_OFFSET is used in compiler-generated inline tag
checks[1], which must only attempt to dereference canonical addresses.
However, for KASAN_SW_TAGS there is some freedom to change the algorithm
without breaking the ABI. Because TBI is enabled for kernel addresses,
the top bits of shadow memory addresses computed during tag checks are
irrelevant, and so likewise are the top bits of KASAN_SHADOW_OFFSET.
This is demonstrated by the fact that LLVM uses a logical right shift in
the tag check fast path[2] but a sbfx (signed bitfield extract)
instruction in the slow path[3] without causing any issues.
Use an arithmetic shift in kasan_mem_to_shadow() as it provides a number
of benefits:
1) The memory layout doesn't change but is easier to understand.
KASAN_SHADOW_OFFSET becomes a canonical memory address, and the shifted
pointer becomes a negative offset, so KASAN_SHADOW_OFFSET ==
KASAN_SHADOW_END regardless of the shift amount or the size of the
virtual address space.
2) KASAN_SHADOW_OFFSET becomes a simpler constant, requiring only one
instruction to load instead of two. Since it must be loaded in each
function with a tag check, this decreases kernel text size by 0.5%.
3) This shift and the sign extension from kasan_reset_tag() can be
combined into a single sbfx instruction. When this same algorithm change
is applied to the compiler, it removes an instruction from each inline
tag check, further reducing kernel text size by an additional 4.6%.
These benefits extend to other architectures as well. On RISC-V, where
the baseline ISA does not shifted addition or have an equivalent to the
sbfx instruction, loading KASAN_SHADOW_OFFSET is reduced from 3 to 2
instructions, and kasan_mem_to_shadow(kasan_reset_tag(addr)) similarly
combines two consecutive right shifts.
Link: https://github.com/llvm/llvm-project/blob/llvmorg-20-init/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp#L1316 [1]
Link: https://github.com/llvm/llvm-project/blob/llvmorg-20-init/llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp#L895 [2]
Link: https://github.com/llvm/llvm-project/blob/llvmorg-20-init/llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp#L669 [3]
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
Co-developed-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
Changelog v11: (Maciej)
- Remove the arch_kasan_non_canonical_hook() scheme in favor of Andrey
Ryabinin's much nicer simple implementation.
Changelog v10: (Maciej)
- Update the Documentation/dev-tools/kasan.rst file with the changed
kasan_mem_to_shadow().
Changelog v9: (Maciej)
- Take out the arm64 related code from mm/kasan/report.c and put it in
the arch specific directory in a new file so the kasan_mem_to_shadow()
function can be included.
- Reset addr tag bits in arm64's arch_kasan_non_canonical_hook() so the
inline mode can also work with that function (Andrey Ryabinin).
- Fix incorrect number of zeros in a comment in mm/kasan/report.c.
- Remove Catalin's acked-by since changes were made.
Changelog v7: (Maciej)
- Change UL to ULL in report.c to fix some compilation warnings.
Changelog v6: (Maciej)
- Add Catalin's acked-by.
- Move x86 gdb snippet here from the last patch.
Changelog v5: (Maciej)
- (u64) -> (unsigned long) in report.c
Changelog v4: (Maciej)
- Revert x86 to signed mem_to_shadow mapping.
- Remove last two paragraphs since they were just poorer duplication of
the comments in kasan_non_canonical_hook().
Changelog v3: (Maciej)
- Fix scripts/gdb/linux/kasan.py so the new signed mem_to_shadow() is
reflected there.
- Fix Documentation/arch/arm64/kasan-offsets.sh to take new offsets into
account.
- Made changes to the kasan_non_canonical_hook() according to upstream
discussion. Settled on overflow on both ranges and separate checks for
x86 and arm.
Changelog v2: (Maciej)
- Correct address range that's checked in kasan_non_canonical_hook().
Adjust the comment inside.
- Remove part of comment from arch/arm64/include/asm/memory.h.
- Append patch message paragraph about the overflow in
kasan_non_canonical_hook().
Documentation/arch/arm64/kasan-offsets.sh | 8 ++++++--
Documentation/dev-tools/kasan.rst | 18 ++++++++++++------
arch/arm64/Kconfig | 10 +++++-----
arch/arm64/include/asm/memory.h | 14 +++++++++++++-
arch/arm64/mm/kasan_init.c | 7 +++++--
include/linux/kasan.h | 10 ++++++++--
mm/kasan/report.c | 16 ++++++++++++----
scripts/gdb/linux/kasan.py | 5 ++++-
scripts/gdb/linux/mm.py | 5 +++--
9 files changed, 68 insertions(+), 25 deletions(-)
diff --git a/Documentation/arch/arm64/kasan-offsets.sh b/Documentation/arch/arm64/kasan-offsets.sh
index 2dc5f9e18039..ce777c7c7804 100644
--- a/Documentation/arch/arm64/kasan-offsets.sh
+++ b/Documentation/arch/arm64/kasan-offsets.sh
@@ -5,8 +5,12 @@
print_kasan_offset () {
printf "%02d\t" $1
- printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) \
- - (1 << (64 - 32 - $2)) ))
+ if [[ $2 -ne 4 ]] then
+ printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) \
+ - (1 << (64 - 32 - $2)) ))
+ else
+ printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) ))
+ fi
}
echo KASAN_SHADOW_SCALE_SHIFT = 3
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index 4968b2aa60c8..b11c1be8dff4 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -315,13 +315,19 @@ translate a memory address to its corresponding shadow address.
Here is the function which translates an address to its corresponding shadow
address::
- static inline void *kasan_mem_to_shadow(const void *addr)
- {
- return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
- + KASAN_SHADOW_OFFSET;
- }
+ static inline void *kasan_mem_to_shadow(const void *addr)
+ {
+ void *scaled;
-where ``KASAN_SHADOW_SCALE_SHIFT = 3``.
+ if (IS_ENABLED(CONFIG_KASAN_GENERIC))
+ scaled = (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT);
+ else
+ scaled = (void *)((long)addr >> KASAN_SHADOW_SCALE_SHIFT);
+
+ return KASAN_SHADOW_OFFSET + scaled;
+ }
+
+where for Generic KASAN ``KASAN_SHADOW_SCALE_SHIFT = 3``.
Compile-time instrumentation is used to insert memory access checks. Compiler
inserts function calls (``__asan_load*(addr)``, ``__asan_store*(addr)``) before
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bcd9f5bc66e2..87239396ed23 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -434,11 +434,11 @@ config KASAN_SHADOW_OFFSET
default 0xdffffe0000000000 if ARM64_VA_BITS_42 && !KASAN_SW_TAGS
default 0xdfffffc000000000 if ARM64_VA_BITS_39 && !KASAN_SW_TAGS
default 0xdffffff800000000 if ARM64_VA_BITS_36 && !KASAN_SW_TAGS
- default 0xefff800000000000 if (ARM64_VA_BITS_48 || (ARM64_VA_BITS_52 && !ARM64_16K_PAGES)) && KASAN_SW_TAGS
- default 0xefffc00000000000 if (ARM64_VA_BITS_47 || ARM64_VA_BITS_52) && ARM64_16K_PAGES && KASAN_SW_TAGS
- default 0xeffffe0000000000 if ARM64_VA_BITS_42 && KASAN_SW_TAGS
- default 0xefffffc000000000 if ARM64_VA_BITS_39 && KASAN_SW_TAGS
- default 0xeffffff800000000 if ARM64_VA_BITS_36 && KASAN_SW_TAGS
+ default 0xffff800000000000 if (ARM64_VA_BITS_48 || (ARM64_VA_BITS_52 && !ARM64_16K_PAGES)) && KASAN_SW_TAGS
+ default 0xffffc00000000000 if (ARM64_VA_BITS_47 || ARM64_VA_BITS_52) && ARM64_16K_PAGES && KASAN_SW_TAGS
+ default 0xfffffe0000000000 if ARM64_VA_BITS_42 && KASAN_SW_TAGS
+ default 0xffffffc000000000 if ARM64_VA_BITS_39 && KASAN_SW_TAGS
+ default 0xfffffff800000000 if ARM64_VA_BITS_36 && KASAN_SW_TAGS
default 0xffffffffffffffff
config UNWIND_TABLES
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index a2b7a33966ff..875c0bd0d85a 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -89,7 +89,15 @@
*
* KASAN_SHADOW_END is defined first as the shadow address that corresponds to
* the upper bound of possible virtual kernel memory addresses UL(1) << 64
- * according to the mapping formula.
+ * according to the mapping formula. For Generic KASAN, the address in the
+ * mapping formula is treated as unsigned (part of the compiler's ABI), so the
+ * end of the shadow memory region is at a large positive offset from
+ * KASAN_SHADOW_OFFSET. For Software Tag-Based KASAN, the address in the
+ * formula is treated as signed. Since all kernel addresses are negative, they
+ * map to shadow memory below KASAN_SHADOW_OFFSET, making KASAN_SHADOW_OFFSET
+ * itself the end of the shadow memory region. (User pointers are positive and
+ * would map to shadow memory above KASAN_SHADOW_OFFSET, but shadow memory is
+ * not allocated for them.)
*
* KASAN_SHADOW_START is defined second based on KASAN_SHADOW_END. The shadow
* memory start must map to the lowest possible kernel virtual memory address
@@ -100,7 +108,11 @@
*/
#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
#define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL)
+#ifdef CONFIG_KASAN_GENERIC
#define KASAN_SHADOW_END ((UL(1) << (64 - KASAN_SHADOW_SCALE_SHIFT)) + KASAN_SHADOW_OFFSET)
+#else
+#define KASAN_SHADOW_END KASAN_SHADOW_OFFSET
+#endif
#define _KASAN_SHADOW_START(va) (KASAN_SHADOW_END - (UL(1) << ((va) - KASAN_SHADOW_SCALE_SHIFT)))
#define KASAN_SHADOW_START _KASAN_SHADOW_START(vabits_actual)
#define PAGE_END KASAN_SHADOW_START
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index abeb81bf6ebd..937f6eb8115b 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -198,8 +198,11 @@ static bool __init root_level_aligned(u64 addr)
/* The early shadow maps everything to a single page of zeroes */
asmlinkage void __init kasan_early_init(void)
{
- BUILD_BUG_ON(KASAN_SHADOW_OFFSET !=
- KASAN_SHADOW_END - (1UL << (64 - KASAN_SHADOW_SCALE_SHIFT)));
+ if (IS_ENABLED(CONFIG_KASAN_GENERIC))
+ BUILD_BUG_ON(KASAN_SHADOW_OFFSET !=
+ KASAN_SHADOW_END - (1UL << (64 - KASAN_SHADOW_SCALE_SHIFT)));
+ else
+ BUILD_BUG_ON(KASAN_SHADOW_OFFSET != KASAN_SHADOW_END);
BUILD_BUG_ON(!IS_ALIGNED(_KASAN_SHADOW_START(VA_BITS), SHADOW_ALIGN));
BUILD_BUG_ON(!IS_ALIGNED(_KASAN_SHADOW_START(VA_BITS_MIN), SHADOW_ALIGN));
BUILD_BUG_ON(!IS_ALIGNED(KASAN_SHADOW_END, SHADOW_ALIGN));
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index bf233bde68c7..fbff1b759c85 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -62,8 +62,14 @@ int kasan_populate_early_shadow(const void *shadow_start,
#ifndef kasan_mem_to_shadow
static inline void *kasan_mem_to_shadow(const void *addr)
{
- return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
- + KASAN_SHADOW_OFFSET;
+ void *scaled;
+
+ if (IS_ENABLED(CONFIG_KASAN_GENERIC))
+ scaled = (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT);
+ else
+ scaled = (void *)((long)addr >> KASAN_SHADOW_SCALE_SHIFT);
+
+ return KASAN_SHADOW_OFFSET + scaled;
}
#endif
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index e804b1e1f886..1e4521b5ef14 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -640,12 +640,20 @@ void kasan_non_canonical_hook(unsigned long addr)
{
unsigned long orig_addr, user_orig_addr;
const char *bug_type;
+ void *tagged_null = set_tag(NULL, KASAN_TAG_KERNEL);
+ void *tagged_addr = set_tag((void *)addr, KASAN_TAG_KERNEL);
/*
- * All addresses that came as a result of the memory-to-shadow mapping
- * (even for bogus pointers) must be >= KASAN_SHADOW_OFFSET.
+ * Filter out addresses that cannot be shadow memory accesses generated
+ * by the compiler.
+ *
+ * In SW_TAGS mode, when computing a shadow address, the compiler always
+ * sets the kernel tag (some top bits) on the pointer *before* computing
+ * the memory-to-shadow mapping. As a result, valid shadow addresses
+ * are derived from tagged kernel pointers.
*/
- if (addr < KASAN_SHADOW_OFFSET)
+ if (tagged_addr < kasan_mem_to_shadow(tagged_null) ||
+ tagged_addr > kasan_mem_to_shadow((void *)(~0ULL)))
return;
orig_addr = (unsigned long)kasan_shadow_to_mem((void *)addr);
@@ -670,7 +678,7 @@ void kasan_non_canonical_hook(unsigned long addr)
} else if (user_orig_addr < TASK_SIZE) {
bug_type = "probably user-memory-access";
orig_addr = user_orig_addr;
- } else if (addr_in_shadow((void *)addr))
+ } else if (addr_in_shadow(tagged_addr))
bug_type = "probably wild-memory-access";
else
bug_type = "maybe wild-memory-access";
diff --git a/scripts/gdb/linux/kasan.py b/scripts/gdb/linux/kasan.py
index 56730b3fde0b..4b86202b155f 100644
--- a/scripts/gdb/linux/kasan.py
+++ b/scripts/gdb/linux/kasan.py
@@ -7,7 +7,8 @@
#
import gdb
-from linux import constants, mm
+from linux import constants, utils, mm
+from ctypes import c_int64 as s64
def help():
t = """Usage: lx-kasan_mem_to_shadow [Hex memory addr]
@@ -39,6 +40,8 @@ class KasanMemToShadow(gdb.Command):
else:
help()
def kasan_mem_to_shadow(self, addr):
+ if constants.CONFIG_KASAN_SW_TAGS and not utils.is_target_arch('x86'):
+ addr = s64(addr)
return (addr >> self.p_ops.KASAN_SHADOW_SCALE_SHIFT) + self.p_ops.KASAN_SHADOW_OFFSET
KasanMemToShadow()
diff --git a/scripts/gdb/linux/mm.py b/scripts/gdb/linux/mm.py
index d78908f6664d..d4ab341d89c5 100644
--- a/scripts/gdb/linux/mm.py
+++ b/scripts/gdb/linux/mm.py
@@ -281,12 +281,13 @@ class aarch64_page_ops():
self.KERNEL_END = gdb.parse_and_eval("_end")
if constants.LX_CONFIG_KASAN_GENERIC or constants.LX_CONFIG_KASAN_SW_TAGS:
+ self.KASAN_SHADOW_OFFSET = constants.LX_CONFIG_KASAN_SHADOW_OFFSET
if constants.LX_CONFIG_KASAN_GENERIC:
self.KASAN_SHADOW_SCALE_SHIFT = 3
+ self.KASAN_SHADOW_END = (1 << (64 - self.KASAN_SHADOW_SCALE_SHIFT)) + self.KASAN_SHADOW_OFFSET
else:
self.KASAN_SHADOW_SCALE_SHIFT = 4
- self.KASAN_SHADOW_OFFSET = constants.LX_CONFIG_KASAN_SHADOW_OFFSET
- self.KASAN_SHADOW_END = (1 << (64 - self.KASAN_SHADOW_SCALE_SHIFT)) + self.KASAN_SHADOW_OFFSET
+ self.KASAN_SHADOW_END = self.KASAN_SHADOW_OFFSET
self.PAGE_END = self.KASAN_SHADOW_END - (1 << (self.vabits_actual - self.KASAN_SHADOW_SCALE_SHIFT))
else:
self.PAGE_END = self._PAGE_END(self.VA_BITS_MIN)
--
2.53.0
^ permalink raw reply related
* [PATCH v12 00/15] kasan: x86: arm64: KASAN tag-based mode for x86
From: Maciej Wieczor-Retman @ 2026-03-30 14:31 UTC (permalink / raw)
To: vbabka, glider, ryabinin.a.a, urezki, tglx, jeremy.linton,
osandov, ritesh.list, morbo, axelrasmussen, ankur.a.arora, baohua,
tabba, catalin.marinas, surenb, maciej.wieczor-retman,
vincenzo.frascino, will, kasong, qi.zheng, hsj0512, shakeel.butt,
weixugc, kees, akpm, yeoreum.yun, jgross, justinstitt,
trintaeoitogc, nick.desaulniers+lkml, corbet, samuel.holland,
Liam.Howlett, rppt, mhocko, jackmanb, mingo, linmag7, kas, ardb,
leitao, david, skhan, thuth, hpa, andreyknvl, luto, maz, dvyukov,
nsc, houwenlong.hwl, bp, jan.kiszka, kevin.brodsky, nathan,
peterz, yuanchu, dave.hansen, kbingham, ljs
Cc: linux-mm, linux-arm-kernel, linux-doc, workflows, llvm, kasan-dev,
linux-kbuild, linux-kernel, x86, m.wieczorretman
======= Introduction
The patchset aims to add a KASAN tag-based mode for the x86 architecture
with the help of the new CPU feature called Linear Address Masking
(LAM). Main improvement introduced by the series is 2x lower memory
usage compared to KASAN's generic mode, the only currently available
mode on x86. The tag based mode may also find errors that the generic
mode couldn't because of differences in how these modes operate.
======= How does KASAN' tag-based mode work?
When enabled, memory accesses and allocations are augmented by the
compiler during kernel compilation. Instrumentation functions are added
to each memory allocation and each pointer dereference.
The allocation related functions generate a random tag and save it in
two places: in shadow memory that maps to the allocated memory, and in
the top bits of the pointer that points to the allocated memory. Storing
the tag in the top of the pointer is possible because of Top-Byte Ignore
(TBI) on arm64 architecture and LAM on x86.
The access related functions are performing a comparison between the tag
stored in the pointer and the one stored in shadow memory. If the tags
don't match an out of bounds error must have occurred and so an error
report is generated.
The general idea for the tag-based mode is very well explained in the
series with the original implementation [1].
[1] https://lore.kernel.org/all/cover.1544099024.git.andreyknvl@google.com/
======= Differences summary compared to the arm64 tag-based mode
- Tag width:
- Tag width influences the chance of a tag mismatch due to two
tags from different allocations having the same value. The
bigger the possible range of tag values the lower the chance
of that happening.
- Shortening the tag width from 8 bits to 4, while it can help
with memory usage, it also increases the chance of not
reporting an error. 4 bit tags have a ~7% chance of a tag
mismatch.
- Address masking mechanism
- TBI in arm64 allows for storing metadata in the top 8 bits of
the virtual address.
- LAM in x86 allows storing tags in bits [62:57] of the pointer.
To maximize memory savings the tag width is reduced to bits
[60:57].
- Inline mode mismatch reporting
- Arm64 inserts a BRK instruction to pass metadata about a tag
mismatch to the KASAN report.
- Right now on x86 the INT3 instruction is used for the same
purpose. The attempt to move it over to use UD1 is already
implemented and tested but relies on another series that needs
merging first. Therefore this patch will be posted separately
once the dependency is satisfied by being merged upstream.
======= Testing
Checked all the kunits for both software tags and generic KASAN after
making changes.
In generic mode (both with these patches and without) the results were:
kasan: pass:61 fail:1 skip:14 total:76
Totals: pass:61 fail:1 skip:14 total:76
not ok 1 kasan
and for software tags:
kasan: pass:65 fail:1 skip:10 total:76
Totals: pass:65 fail:1 skip:10 total:76
not ok 1 kasan
At the time of testing the one failing case is also present on generic
mode without this patchset applied. This seems to point to something
else being at fault for the one case not passing. The test case in
question concerns strscpy() out of bounds error not getting caught.
======= Benchmarks [1]
All tests were ran on a Sierra Forest server platform. The only
differences between the tests were kernel options:
- CONFIG_KASAN
- CONFIG_KASAN_GENERIC
- CONFIG_KASAN_SW_TAGS
- CONFIG_KASAN_INLINE [1]
- CONFIG_KASAN_OUTLINE
Boot time (until login prompt):
* 02:55 for clean kernel
* 05:42 / 06:32 for generic KASAN (inline/outline)
* 05:58 for tag-based KASAN (outline) [2]
Total memory usage (512GB present on the system - MemAvailable just
after boot):
* 12.56 GB for clean kernel
* 81.74 GB for generic KASAN
* 44.39 GB for tag-based KASAN
Kernel size:
* 14 MB for clean kernel
* 24.7 MB / 19.5 MB for generic KASAN (inline/outline)
* 27.1 MB / 18.1 MB for tag-based KASAN (inline/outline)
Work under load time comparison (compiling the mainline kernel) (200 cores):
* 62s for clean kernel
* 171s / 125s for generic KASAN (outline/inline)
* 145s for tag-based KASAN (outline) [2]
[1] Currently inline mode doesn't work on x86 due to things missing in
the compiler. I have written a patch for clang that seems to fix the
inline mode and I was able to boot and check that all patches regarding
the inline mode work as expected. My hope is to post the patch to LLVM
once this series is completed, and then make inline mode available in
the kernel config.
[2] While I was able to boot the inline tag-based kernel with my
compiler changes in a simulated environment, due to toolchain
difficulties I couldn't get it to boot on the machine I had access to.
Also boot time results from the simulation seem too good to be true, and
they're much too worse for the generic case to be believable. Therefore
I'm posting only results from the physical server platform.
======= Compilation
Clang was used to compile the series (make LLVM=1) since gcc doesn't
seem to have support for KASAN tag-based compiler instrumentation on
x86. Patchset does seem to compile with gcc without an issue but doesn't
boot afterwards.
======= Dependencies
The series is based on mm-new.
======= Previous versions
v11: https://lore.kernel.org/all/cover.1773164688.git.m.wieczorretman@pm.me/
v10: https://lore.kernel.org/all/cover.1770232424.git.m.wieczorretman@pm.me/
v9: https://lore.kernel.org/all/cover.1768845098.git.m.wieczorretman@pm.me/
v8: https://lore.kernel.org/all/cover.1768233085.git.m.wieczorretman@pm.me/
v7: https://lore.kernel.org/all/cover.1765386422.git.m.wieczorretman@pm.me/
v6: https://lore.kernel.org/all/cover.1761763681.git.m.wieczorretman@pm.me/
v5: https://lore.kernel.org/all/cover.1756151769.git.maciej.wieczor-retman@intel.com/
v4: https://lore.kernel.org/all/cover.1755004923.git.maciej.wieczor-retman@intel.com/
v3: https://lore.kernel.org/all/cover.1743772053.git.maciej.wieczor-retman@intel.com/
v2: https://lore.kernel.org/all/cover.1739866028.git.maciej.wieczor-retman@intel.com/
v1: https://lore.kernel.org/all/cover.1738686764.git.maciej.wieczor-retman@intel.com/
=== (two fixes patches were split off after v6) (merged into mm-unstable)
v1: https://lore.kernel.org/all/cover.1762267022.git.m.wieczorretman@pm.me/
v2: https://lore.kernel.org/all/cover.1764685296.git.m.wieczorretman@pm.me/
v3: https://lore.kernel.org/all/cover.1764874575.git.m.wieczorretman@pm.me/
v4: https://lore.kernel.org/all/cover.1764945396.git.m.wieczorretman@pm.me/
Changes v12:
- Put CC_IS_CLANG and ADDRESS_MASKING into one Kconfig option that
controls HAVE_ARCH_KASAN_SW_TAGS. (Peter Zijlstra)
Changes v11:
- Rebase series onto mm-new.
- Split off and modify the documentation patch.
- Split the pointer arithmetic reset tag patch in two. One patch for
slight rework of page_to_virt() and one for putting x -
__START_KERNEL_map into a tag reset helper.
- Fix issue pointed out by Dave on copy_from_kernel_nofault_allowed().
- Remove the arch_kasan_non_canonical_hook function scheme in favor of
Andrey Ryabinin's simpler arch independent implementation.
Changes v10:
- Rebase the series onto 6.19-rc8.
- Add Mike Rapoport's acked-by to patch 6.
- Modify Documentation/dev-tools/kasan.rst in patches 1 and 13.
Changes v9:
- Lock HAVE_ARCH_KASAN_SW_TAGS behind CC_IS_CLANG due to gcc not working
in practice.
- Remove pr_info() from KASAN initialization.
- Add paragraph to mm.rst explaining the alternative KASAN memory
ranges.
- Move out arch based code from kasan_non_canonical_hook() into arch
subdirectories. arm64 and non-arch changes in patch 1, x86 changes in
patch 12.
- Reset tag bits on arm64's non-canonical hook to allow inline mode to
work.
- Revert modifying __is_canonical_address() since it can break KVM. Just
untag address in copy_from_kernel_no_fault_allowed().
- Add a bunch of reviewed-by tags.
Changes v8:
- Detached the UD1/INT3 inline patch from the series so the whole
patchset can be merged without waiting on other dependency series. For
now with lack of compiler support for the inline mode that patch
didn't work anyway so this delay is not an issue.
- Rebased patches onto 6.19-rc5.
- Added acked-by tag to "kasan: arm64: x86: Make special tags arch
specific".
Changes v7:
- Rebased the series onto Peter Zijlstra's "WARN() hackery" v2 patchset.
- Fix flipped memset arguments in "x86/kasan: KASAN raw shadow memory
PTE init".
- Reorder tag width defines on arm64 to avoid redefinition warnings.
- Split off the pcpu unpoison patches into a separate fix oriented
series.
- Redid the canonicality checks so it works for KVM too (didn't change
the __canonical_address() function previously).
- A lot of fixes pointed out by Alexander in his great review:
- Fixed "x86/mm: Physical address comparisons in fill_p*d/pte"
- Merged "Support tag widths less than 8 bits" and "Make special
tags arch specific".
- Added comments and extended patch messages for patches
"x86/kasan: Make software tag-based kasan available" and
"mm/execmem: Untag addresses in EXECMEM_ROX related pointer arithmetic",
- Fixed KASAN_TAG_MASK definition order so all patches compile
individually.
- Renamed kasan_inline.c to kasan_sw_tags.c.
Changes v6:
- Initialize sw-tags only when LAM is available.
- Move inline mode to use UD1 instead of INT3
- Remove inline multishot patch.
- Fix the canonical check to work for user addresses too.
- Revise patch names and messages to align to tip tree rules.
- Fix vdso compilation issue.
Changes v5:
- Fix a bunch of arm64 compilation errors I didn't catch earlier.
Thank You Ada for testing the series!
- Simplify the usage of the tag handling x86 functions (virt_to_page,
phys_addr etc.).
- Remove within() and within_range() from the EXECMEM_ROX patch.
Changes v4:
- Revert x86 kasan_mem_to_shadow() scheme to the same on used in generic
KASAN. Keep the arithmetic shift idea for the KASAN in general since
it makes more sense for arm64 and in risc-v.
- Fix inline mode but leave it unavailable until a complementary
compiler patch can be merged.
- Apply Dave Hansen's comments on series formatting, patch style and
code simplifications.
Changes v3:
- Remove the runtime_const patch and setup a unified offset for both 5
and 4 paging levels.
- Add a fix for inline mode on x86 tag-based KASAN. Add a handler for
int3 that is generated on inline tag mismatches.
- Fix scripts/gdb/linux/kasan.py so the new signed mem_to_shadow() is
reflected there.
- Fix Documentation/arch/arm64/kasan-offsets.sh to take new offsets into
account.
- Made changes to the kasan_non_canonical_hook() according to upstream
discussion.
- Remove patches 2 and 3 since they related to risc-v and this series
adds only x86 related things.
- Reorder __tag_*() functions so they're before arch_kasan_*(). Remove
CONFIG_KASAN condition from __tag_set().
Changes v2:
- Split the series into one adding KASAN tag-based mode (this one) and
another one that adds the dense mode to KASAN (will post later).
- Removed exporting kasan_poison() and used a wrapper instead in
kasan_init_64.c
- Prepended series with 4 patches from the risc-v series and applied
review comments to the first patch as the rest already are reviewed.
Maciej Wieczor-Retman (13):
kasan: Fix inline mode for x86 tag-based mode
x86/kasan: Add arch specific kasan functions
x86/mm: Reset pointer tag in x - __START_KERNEL_map instances
kasan: arm64: x86: Make page_to_virt() KASAN aware
mm/execmem: Untag addresses in EXECMEM_ROX related pointer arithmetic
x86/mm: Use physical address comparisons in fill_p*d/pte
x86/kasan: Initialize KASAN raw shadow memory
x86/mm: Reset tags in a canonical address helper call
x86/mm: Initialize LAM_SUP
x86: Increase minimal SLAB alignment for KASAN
x86/kasan: Use a logical bit shift for kasan_mem_to_shadow
x86/kasan: Make software tag-based kasan available
docs: Update KASAN and x86 memory map documentations
Samuel Holland (2):
kasan: sw_tags: Use arithmetic shift for shadow computation
kasan: arm64: x86: Make special tags arch specific
Documentation/arch/arm64/kasan-offsets.sh | 8 ++-
Documentation/arch/x86/x86_64/mm.rst | 21 +++++-
Documentation/dev-tools/kasan.rst | 79 ++++++++++++++++-------
MAINTAINERS | 2 +-
arch/arm64/Kconfig | 10 +--
arch/arm64/include/asm/kasan-tags.h | 14 ++++
arch/arm64/include/asm/kasan.h | 2 -
arch/arm64/include/asm/memory.h | 19 ++++--
arch/arm64/include/asm/uaccess.h | 1 +
arch/arm64/mm/kasan_init.c | 7 +-
arch/x86/Kconfig | 9 +++
arch/x86/boot/compressed/misc.h | 1 +
arch/x86/include/asm/cache.h | 4 ++
arch/x86/include/asm/kasan-tags.h | 9 +++
arch/x86/include/asm/kasan.h | 62 +++++++++++++++++-
arch/x86/include/asm/page_64.h | 11 +++-
arch/x86/kernel/head_64.S | 3 +
arch/x86/mm/init.c | 3 +
arch/x86/mm/init_64.c | 11 ++--
arch/x86/mm/kasan_init_64.c | 24 ++++++-
arch/x86/mm/maccess.c | 1 +
arch/x86/mm/physaddr.c | 4 +-
include/linux/kasan-tags.h | 21 ++++--
include/linux/kasan.h | 23 +++++--
include/linux/mm.h | 11 ++--
include/linux/mmzone.h | 2 +-
include/linux/page-flags-layout.h | 9 +--
lib/Kconfig.kasan | 4 +-
mm/execmem.c | 9 ++-
mm/kasan/report.c | 16 +++--
mm/vmalloc.c | 7 +-
scripts/Makefile.kasan | 3 +
scripts/gdb/linux/kasan.py | 5 +-
scripts/gdb/linux/mm.py | 5 +-
34 files changed, 331 insertions(+), 89 deletions(-)
create mode 100644 arch/arm64/include/asm/kasan-tags.h
create mode 100644 arch/x86/include/asm/kasan-tags.h
--
2.53.0
^ permalink raw reply
* Re: [PATCH] checkpatch: allow correctly handle full files on stdin
From: Vlastimil Babka @ 2026-03-30 9:40 UTC (permalink / raw)
To: Joe Perches, Dmitry Torokhov
Cc: Dwaipayan Ray, Lukas Bulwahn, Andy Whitcroft, Jonathan Corbet,
Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <f4dcaecb682c4eaa271abfee27c7cc8f6fbf7d1d.camel@perches.com>
On 3/27/26 00:19, Joe Perches wrote:
> On Thu, 2026-03-26 at 16:04 -0700, Dmitry Torokhov wrote:
>> In all seriousness, if you will not make use of this mode it's fine. But
>> it allows keeping the source cleaner as one makes edits, so why not
>> enable this?
>
> Unnecessary complication.
Are you maintaining a tool that you want to be useful to others, or to only
do stricly what you personally think is necessary?
I don't understand your objections to this rather straightforward patch, it
doesn't look like a maintenance burden to me?
^ 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