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

[Greg KH <greg@kroah.com>]

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