On Sun, Apr 26, 2026 at 06:39:13PM +0200, Willy Tarreau wrote: > +In the Linux kernel's threat model, an issue is **not** a security bug, and > +should not be reported to the security list, when triggering it requires the > +reporter to first undermine the system they are attacking. This includes, > but > +is not limited to, behavior that only manifests after the administrator has > +explicitly enabled it (loading a module, setting a sysctl, writing to a > debugfs > +knob, or otherwise using an interface documented as privileged or unsafe); > bugs > +reachable only through root or CAP_SYS_ADMIN or CAP_NET_ADMIN on a machine > the > +actor already fully controls, with no further privilege boundary being > crossed; > +prediction of random numbers that only works in a totally silent environment > +(such as IP ID, TCP ports or sequence numbers that can only be guessed in a > +lab), issues that appear only in debug, lockdep, KASAN, fault-injection, > +CONFIG_NOMMU, or other developer-oriented kernel builds that are not intended > +for production use; problems seen only under development simulators, > emulators, > +or fuzzing harnesses that present hardware or input states which cannot occur > +on real systems; bugs that require modified or emulated hardware; missing > +hardening or defence-in-depth suggestions with no demonstrable exploit path > +(including local ASLR bypass); mounting file systems that would be fixed or > +rejected by fsck; and bugs in out-of-tree modules or vendor forks, which > should > +be reported to the relevant vendor. Functional and performance regressions, > +and disagreements with documented kernel policy (for example, "root can load > +modules"), are likewise ordinary bugs or feature requests rather than > security > +issues, and should be reported via the usual channels.
This is a great list to start with, but perhaps we should put it in list form so that it's easier to read? Also, I can see this turning into a separate document eventually as different subsystems should have a chance to weigh in on what they consider the threat model to be (like what the IB subsystem does which I don't think you listed above, or the USB subsystem.) thanks, greg k-h
