Linus Torvalds has merged new Linux kernel documentation that clarifies how security-related bugs should be reported, triaged, and handled, including cases involving AI-assisted vulnerability reports, addressing the increasing number of low-quality reports submitted as security fixes.
The change was introduced via the docs-7.1-fixes pull request and adds process documentation for the Linux kernel security bug model. Willy Tarreau, recognized for HAProxy and Linux kernel stable maintenance, authored the new documentation. It clarifies which bugs qualify as security vulnerabilities and which should remain in the standard public development process.
The kernel project maintains that most security-related bugs should be addressed publicly, as broader review leads to better fixes. The private security list is reserved for urgent, easily exploitable vulnerabilities that impact many users and allow attackers to gain elevated privileges.
The update directly addresses AI-assisted vulnerability reports. New guidance states that issues found with AI assistants should typically be discussed publicly, as multiple researchers may discover them simultaneously. Exploit code should not be shared publicly; instead, reporters may confirm a working exploit exists and provide it privately upon request from a maintainer.
A separate section outlines quality requirements for AI-generated or AI-assisted reports. Maintainers request concise plain-text reports without Markdown, with key facts at the beginning. Reports should describe verified impacts, such as whether a bug allows an unprivileged user to gain a specific capability, rather than speculative outcomes.
The documentation requires reporters to test AI-generated exploits before submitting and to confirm the issue is reproducible. It also encourages using AI to develop and test fixes, not just to identify vulnerabilities.
A key component of the update is the new Linux kernel threat model. It lists guarantees whose violation may constitute a vulnerability, including user-level isolation, process memory separation, restrictions on ptrace, IPC and network isolation, and protections enforced by Linux capabilities such as CAP_SYS_ADMIN, CAP_NET_ADMIN, and CAP_SYS_PTRACE.
The document also addresses user namespaces, stating that CONFIG_USER_NS lets unprivileged users create isolated environments that must not impact the global namespace. It also covers debugging interfaces such as /proc/kmsg, perf, and debugfs, emphasizing that access to sensitive information through these interfaces requires explicit administrator permission.
Moreover, the new documentation clarifies which issues should not automatically be considered vulnerabilities. These include problems from obsolete kernel branches, unsafe build options, insecure sysctl or filesystem permissions, development-only features such as LOCKDEP, KASAN, and FAULT_INJECTION, and code in staging or experimental areas.
Finally, the same standard applies also to reports that require excessive privileges, unrealistic lab conditions, modified hardware, an impractical number of attempts, or configurations far from normal use. In addition, the document excludes theoretical bypasses without a working exploit, uncontrolled information leaks, and filesystem image issues typically handled by tools like fsck.
