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:

"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:

"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 validity of the report should be seriously questioned. Note that since the report will be posted to a public list, the reproducer should only be shared upon maintainers' request.

* **Propose a Fix**: Many AI tools are actually better at writing code than evaluating it. Please ask your tool to propose a fix and **test it** before reporting the problem. If the fix cannot be tested because it relies on rare hardware or almost extinct network protocols, the issue is likely not a security bug. In any case, if a fix is proposed, it must adhere to Documentation/process/submitting-patches.rst and include a 'Fixes:' tag designating the commit that introduced the bug.

Failure to consider these points exposes your report to the risk of being ignored.

Use common sense when evaluating the report. If the affected file has not been touched for more than one year and is maintained by a single individual, it is likely that usage has declined and exposed users are virtually non-existent (e.g., drivers for very old hardware, obsolete filesystems). In such cases, there is no need to consume a maintainer's time with an unimportant report. If the issue is clearly trivial and publicly discoverable, you should report it directly to the public mailing lists."

All of the new Linux kernel bug documentation from Willy Tarreau can be read via this commit that is now in Linux Git ahead of Sunday's Linux 7.1-rc4 release.