Linux Kernel Adds Documentation For What Qualifies As A Security Bug, Responsible AI Use - Phoronix

Articles & Reviews

News Archive

Forums

Premium Ad-Free<br>Contact

Popular Categories

Close

Articles & Reviews

News Archive

Forums

Premium

Contact

Categories

Computers Display Drivers Graphics Cards Linux Gaming Memory Motherboards Processors Software Storage Operating Systems Peripherals

Linux Kernel Adds Documentation For What Qualifies As A Security Bug, Responsible AI Use

Written by Michael Larabel in Linux Kernel on 15 May 2026 at 04:30 PM EDT. 1 Comment

Merged today for the Linux 7.1 kernel is some new documentation surrounding what qualifies as a security bug as well as around responsible use of AI for finding kernel bugs.

Stemming from the recent influx of security bugs to the Linux kernel as well as an uptick in bug and security reports from discoveries made in full or in part with AI, additional documentation was warranted. Longtime Linux developer Willy Tarreau took to authoring the additional documentation around kernel bugs.

As for what qualifies as a security bug with the Linux kernel, the new documentation states:<br>"It is important that most bugs are handled publicly so as to involve the widest possible audience and find the best solution. By nature, bugs that are handled in closed discussions between a small set of participants are less likely to produce the best possible fix (e.g., risk of missing valid use cases, limited testing abilities).

It turns out that the majority of the bugs reported via the security team are just regular bugs that have been improperly qualified as security bugs due to a lack of awareness of the Linux kernel's threat model, as described in Documentation/process/threat-model.rst, and ought to have been sent through the normal channels described in Documentation/admin-guide/reporting-issues.rst instead.

The security list exists for urgent bugs that grant an attacker a capability they are not supposed to have on a correctly configured production system, and can be easily exploited, representing an imminent threat to many users. Before reporting, consider whether the issue actually crosses a trust boundary on such a system.

**If you resorted to AI assistance to identify a bug, you must treat it as public**. While you may have valid reasons to believe it is not, the security team's experience shows that bugs discovered this way systematically surface simultaneously across multiple researchers, often on the same day. In this case, do not publicly share a reproducer, as this could cause unintended harm; just mention that one is available and maintainers might ask for it privately if they need it.

If you are unsure whether an issue qualifies, err on the side of reporting privately: the security team would rather triage a borderline report than miss a real vulnerability. Reporting ordinary bugs to the security list, however, does not make them move faster and consumes triage capacity that other reports need."

And for the responsible use of AI for finding Linux kernel bugs:<br>"A significant fraction of bug reports submitted to the security team are actually the result of code reviews assisted by AI tools. While this can be an efficient means to find bugs in rarely explored areas, it causes an overload on maintainers, who are sometimes forced to ignore such reports due to their poor quality or accuracy. As such, reporters must be particularly cautious about a number of points which tend to make these reports needlessly difficult to handle:

* **Length**: AI-generated reports tend to be excessively long, containing multiple sections and excessive detail. This makes it difficult to spot important information such as affected files, versions, and impact. Please ensure that a clear summary of the problem and all critical details are presented first. Do not require triage engineers to scan multiple pages of text. Configure your tools to produce concise, human-style reports.

* **Formatting**: Most AI-generated reports are littered with Markdown tags. These decorations complicate the search for important information and do not survive the quoting processes involved in forwarding or replying. Please **always convert your report to plain text** without any formatting decorations before sending it.

* **Impact Evaluation**: Many AI-generated reports lack an understanding of the kernel's threat model (see Documentation/process/threat-model.rst) and go to great lengths inventing theoretical consequences. This adds noise and complicates triage. Please stick to verifiable facts (e.g., "this bug permits any user to gain CAP_NET_ADMIN") without enumerating speculative implications. Have your tool read this documentation as part of the evaluation process.

* **Reproducer**: AI-based tools are often capable of generating reproducers. Please always ensure your tool provides one and **test it thoroughly**. If the reproducer does not work, or if the tool cannot produce one, the...