kernel/linux.git/Documentation/process/security-bugs.rst, branch v7.0-rc7

Documentation: fix two typos in latest update to the security report howto

2026-04-04T08:38:43+00:00

In previous patch "Documentation: clarify the mandatory and desirable info for security reports" I left two typos that I didn't detect in local checks. One is "get_maintainers.pl" (no 's' in the script name), and the other one is a missing closing quote after "Reported-by", which didn't have effect here but I don't know if it can break rendering elsewhere (e.g. on the public HTML page). Better fix it before it gets merged. Signed-off-by: Willy Tarreau Link: https://patch.msgid.link/20260404082033.5160-1-w@1wt.eu Signed-off-by: Greg Kroah-Hartman

Documentation: clarify the mandatory and desirable info for security reports

2026-04-03T11:11:23+00:00

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 Cc: Greg KH Signed-off-by: Willy Tarreau Link: https://patch.msgid.link/20260403062018.31080-4-w@1wt.eu Signed-off-by: Greg Kroah-Hartman

Documentation: explain how to find maintainers addresses for security reports

2026-04-03T11:11:23+00:00

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 Cc: Greg KH Signed-off-by: Willy Tarreau Link: https://patch.msgid.link/20260403062018.31080-3-w@1wt.eu Signed-off-by: Greg Kroah-Hartman

Documentation: minor updates to the security contacts

2026-04-03T11:11:23+00:00

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 Cc: Greg KH Signed-off-by: Willy Tarreau Link: https://patch.msgid.link/20260403062018.31080-2-w@1wt.eu Signed-off-by: Greg Kroah-Hartman

Documentation: insist on the plain-text requirement for security reports

2025-12-22T22:32:03+00:00

As the trend of AI-generated reports is growing, the trend of unreadable reports in gimmicky formats is following, and we cannot request that developers rely on online viewers to be able to read a security report full for formatting tags. Let's just insist on the plain text requirement a bit more. Signed-off-by: Willy Tarreau Signed-off-by: Ingo Molnar Reviewed-by: Greg Kroah-Hartman Signed-off-by: Jonathan Corbet Message-ID: <20251129141741.19046-1-w@1wt.eu>

Documentation: smooth the text flow in the security bug reporting process

2025-08-17T10:23:30+00:00

The text was presenting the team, the the e-mail address, then some of the expectations, then what form of e-mail is expected. By switching the e-mail paragraph two paragraphs later and dropping the "Contact" sub-section, we can have a more natural flow that presents the team, then its expectation, then how to best contribute, then where to send. And more importantly, it increases the chances that reporters have read the prerequisites before finding the e-mail address. Signed-off-by: Willy Tarreau Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20250814192730.19252-2-w@1wt.eu Signed-off-by: Greg Kroah-Hartman

Documentation: clarify the expected collaboration with security bugs reporters

2025-08-17T10:23:28+00:00

Some bug reports sent to the security team sometimes lack any explanation, are only AI-generated without verification, or sometimes it can simply be difficult to have a conversation with an invisible reporter belonging to an opaque team. This fortunately remains rare but the trend has been steadily increasing over the last years and it seems important to clarify what developers expect from reporters to avoid frustration on any side and keep the process efficient. Signed-off-by: Willy Tarreau Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20250814192730.19252-1-w@1wt.eu Signed-off-by: Greg Kroah-Hartman

Documentation: Document the Linux Kernel CVE process

2024-02-17T13:46:39+00:00

The Linux kernel project now has the ability to assign CVEs to fixed issues, so document the process and how individual developers can get a CVE if one is not automatically assigned for their fixes. Reviewed-by: Kees Cook Reviewed-by: Konstantin Ryabitsev Reviewed-by: Krzysztof Kozlowski Reviewed-by: Lukas Bulwahn Signed-off-by: Sasha Levin Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/2024021731-essence-sadness-28fd@gregkh Signed-off-by: Greg Kroah-Hartman

Documentation: security-bugs.rst: linux-distros relaxed their rules

2023-10-24T09:25:01+00:00

The linux-distros list relaxed their rules to try to adapt better to how the Linux kernel works. Let's update the Coordination part to explain why and when to contact them or not to and how to avoid trouble in the future. Link: https://www.openwall.com/lists/oss-security/2023/09/08/4 Cc: Kees Cook Cc: Solar Designer Cc: Vegard Nossum Acked-by: Jiri Kosina Signed-off-by: Willy Tarreau Link: https://lore.kernel.org/r/20231015130959.26242-1-w@1wt.eu Signed-off-by: Greg Kroah-Hartman

Documentation: security-bugs.rst: clarify CVE handling

2023-07-17T05:44:10+00:00

The kernel security team does NOT assign CVEs, so document that properly and provide the "if you want one, ask MITRE for it" response that we give on a weekly basis in the document, so we don't have to constantly say it to everyone who asks. Link: https://lore.kernel.org/r/2023063022-retouch-kerosene-7e4a@gregkh Signed-off-by: Greg Kroah-Hartman