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

[Willy Tarreau]

Hi Shuah,

On Fri, May 08, 2026 at 02:52:13PM -0600, Shuah Khan wrote:
> > +What qualifies as a security bug
> > +--------------------------------
> > +
> > +It is important that most bugs are handled publicly so as to involve the widest
> > +possible audience and find the best solution.  By nature, bugs that are handled
> > +in closed discussions between a small set of participants are less likely to
> > +produce the best possible fix (e.g., risk of missing valid use cases, limited
> > +testing abilities).
> > +
> > +It turns out that the majority of the bugs reported via the security team are
> > +just regular bugs that have been improperly qualified as security bugs due to
> > +ignorance or misunderstanding of the Linux kernel's threat model described in
> 
> "lack of understanding" instead of ignorance?

I already had "misunderstanding", here I wanted to express the idea that
people could simply ignore that this file exists (since it's new). Do you
think we shouldn't care about this and just keep "misunderstanding" ?

(...)
> > +The Linux Kernel threat model
> > +=============================
> > +
> > +There are a lot of assumptions regarding what the kernel protects against and
> > +what it does not protect against. These assumptions tend to cause confusion for
> 
> Could simply say "what it does not" or "what the kernel does and does not protect
> against"

Ah OK good point, I'll rephrase it.

> > +* **Configuration**:
> > +
> > +  * outdated kernels and particularly end-of-life branches are out of the scope
> > +    of the kernel's threat model: administrators are responsible for keeping
> > +    their system up to date. For a bug to qualify as a security bug, it must be
> > +    demonstrated that it affects actively maintained versions.
> > +
> > +  * build-level: changes to the kernel configuration that are explicitly
> > +    documented as lowering the security level (e.g. ``CONFIG_NOMMU``), or
> > +    targeted at developers only.
> > +
> > +  * OS-level: changes to command line parameters, sysctls, filesystem
> > +    permissions, user capabilities, exposure of privileged interfaces, that
> > +    explicitly increase exposure by either offering non-default access to
> > +    unprivileged users, or reduce the kernel's ability to enforce some
> > +    protections or mitigations. Example: write access to procfs or debugfs.
> > +
> > +  * issues triggered only when using features intended for development or
> > +    debugging (e.g., lockdep, KASAN, fault-injection): these features are known
> > +    to introduce overhead and potential instability and are not intended for
> > +    production use.
> 
> Can we call out features and tools (the ones in kernel repo)

Sure!

> sched_ext's Kconfig enables
> a few debug options including LOCKDEP
> 
> tools/sched_ext/Kconfig:CONFIG_DEBUG_LOCKDEP=y

It's still there but maybe not visible enough, I should probably write
it in upper case:

   debugging (e.g., lockdep, KASAN, fault-injection):

> > +* **Excess of initial privileges**:
> > +
> > +  * actions performed by a user already possessing the privileges required to
> > +    perform that action or modify that state (e.g. ``CAP_SYS_ADMIN``,
> > +    ``CAP_NET_ADMIN``, ``CAP_SYS_RAWIO``, ``CAP_SYS_MODULE`` with no further
> > +    boundary being crossed).
> > +
> > +  * actions performed in user namespace without permitting anything in the
> > +    initial namespace that was not already permitted to the same user there.
> 
> This was a bit hard to parse - examples might help here

Yeah when rereading it now, I fully agree. I think I should avoid the
double negation here and use a form such as;

  * actions performed in user namespace that do not bypass the restrictions
    imposed to the initial user.

If examples are still needed, I could possibly add: "(e.g. ptrace, signals,
FS or device access, system/network configuration, network binding)".

> > +  * anything performed by the root user in the initial namespace (e.g. kernel
> > +    oops when writing to a privileged device).
> > +
> > +* **Out of production use**:
> > +
> > +  This covers theoretical/probabilistic attacks that rely on laboratory
> > +  conditions with zero system noise, or those requiring an unrealistic number
> > +  of attempts (e.g., billions of trials) that would be detected by standard
> > +  system monitoring long before success, such as:
> > +
> > +  * 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).
> > +
> > +  * activity observation and information leaks based on probabilistic
> > +    approaches that are prone to measurement noise and not realistically
> > +    reproducible on a production system.
> > +
> > +  * issues that can only be triggered by heavy attacks (e.g. brute force) whose
> > +    impact on the system makes it unlikely or impossible to remain undetected
> > +    before they succeed (e.g. consuming all memory before succeeding).
> > +
> > +  * problems seen only under development simulators, emulators, or combinations
> > +    that do not exist on real systems at the time of reporting (issues
> > +    involving tens of millions of threads, tens of thousands of CPUs,
> > +    unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds.
> > +
> > +  * issues whose reproduction requires hardware modification or emulation,
> > +    including fake USB devices that pretend to be another one.
> > +
> > +  * as well as issues that can be triggered at a cost that is orders of
> > +    magnitude higher than the expected benefits (e.g. fully functional keyboard
> > +    emulator only to retrieve 7 uninitialized bytes in a structure, or
> > +    brute-force method involving millions of connection attempts to guess a
> > +    port number).
> 
> Can we add a section about problems found using experimental or tools
> in development stage?

You mean one more paragraph about CONFIG_EXPERIMENTAL ? Or what else do
you have in mind ? Do not hesiate to propose a paragraph if you have
anything in mind!

(...)

> Reviewed-by: Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx>
> 
> thanks,

Thank you!
Willy