kernel/linux.git/Documentation/process/security-bugs.rst, branch v7.1-rc5

docs: security-bugs: add a link to the threat-model documentation

2026-05-14T12:23:06+00:00

Rather than make readers search for this document, just a link to it where it is referenced. (While I was at it, I removed the unused and unneeded _threatmodel label from the top of threat-model.rst). Acked-by: Willy Tarreau Reviewed-by: Greg Kroah-Hartman Signed-off-by: Jonathan Corbet

Documentation: security-bugs: clarify requirements for AI-assisted reports

2026-05-12T17:09:14+00:00

AI tools are increasingly used to assist in bug discovery. While these tools can identify valid issues, reports that are submitted without manual verification often lack context, contain speculative impact assessments, or include unnecessary formatting. Such reports increase triage effort, waste maintainers' time and may be ignored. Reports where the reporter has verified the issue and the proposed fix typically meet quality standards. This documentation outlines specific requirements for length, formatting, and impact evaluation to reduce the effort needed to deal with these reports. Cc: Greg KH Acked-by: Greg Kroah-Hartman Reviewed-by: Leon Romanovsky Signed-off-by: Willy Tarreau Signed-off-by: Jonathan Corbet Message-ID: <20260509094755.2838-4-w@1wt.eu>

Documentation: security-bugs: explain what is and is not a security bug

2026-05-12T17:09:14+00:00

The use of automated tools to find bugs in random locations of the kernel induces a raise of security reports even if most of them should just be reported as regular bugs. This patch is an attempt at drawing a line between what qualifies as a security bug and what does not, hoping to improve the situation and ease decision on the reporter's side. It defers the enumeration to a new file, threat-model.rst, that tries to enumerate various classes of issues that are and are not security bugs. This should permit to more easily update this file for various subsystem-specific rules without having to revisit the security bug reporting guide. Cc: Greg KH Cc: Leon Romanovsky Suggested-by: Leon Romanovsky Suggested-by: Greg KH Reviewed-by: Leon Romanovsky Reviewed-by: Shuah Khan Signed-off-by: Willy Tarreau Reviewed-by: Greg Kroah-Hartman Signed-off-by: Jonathan Corbet Message-ID: <20260509094755.2838-3-w@1wt.eu>

Documentation: security-bugs: do not systematically Cc the security team

2026-05-12T17:09:14+00:00

With the increase of automated reports, the security team is dealing with way more messages than really needed. The reporting process works well with most teams so there is no need to systematically involve the security team in reports. Let's suggest to keep it for small lists of recipients and new reporters only. This should continue to cover the risk of lost messages while reducing the volume from prolific reporters. Cc: Greg KH Cc: Leon Romanovsky Reviewed-by: Leon Romanovsky Reviewed-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau Signed-off-by: Jonathan Corbet Message-ID: <20260509094755.2838-2-w@1wt.eu>

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