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

will receive instructions about whom to contact, if needed.  Your message may

equally be forwarded as-is to the relevant maintainers.

Responsible use of AI to find 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 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.

Sending the report

------------------