Re: [PATCH 2/3] Documentation: security-bugs: explain what is and is not a security bug

[Willy Tarreau]

On Mon, Apr 27, 2026 at 07:48:23AM -0600, Greg KH wrote:
> 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?

In fact that's what I tried first and it was super long with many short
lines, making it possibly worse. But maybe aggregating several short
entries on a line by similarities could work, I can give it a try.

> 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

My fear if we redirect to other files is that it won't be read again.
However, we could possibly suggest to always look for the subsystem's
specific rules in this subsytem's doc, leaving enough freedom to
maintainers to reject more things.

> (like what the IB subsystem does which I
> don't think you listed above, or the USB subsystem.)

Indeed I didn't list IB (I'm never sure about it, I seem to remember
we simply trust any peer, is that right?), nor did I make specific
mentions for USB which is implicitly covered by "hardware emulation
or modification".

thanks!
Willy