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

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Jun 09, 2026 at 11:33:05AM +0300, Askar Safin wrote:
> Willy Tarreau <w@1wt.eu>:
> > +in a way that allows multiple local users to get a fair share of the available
> 
> Your "security-bugs.rst" says that we should consult "threat-model.rst" to
> determine whether a bug should be sent to secret mailing list.
> 
> And "threat-model.rst" says that kernel gives everyone "fair share"
> of resources.
> 
> This can be interpreted so: if scheduler is not fair enough, then this is
> security bug and should be reported to secret mailing list. I don't think
> this is what you meant.

Within reason of course, please use your best judgement.

> > +When hardware fails to maintain its specified isolation (e.g., CPU bugs,
> > +side-channels, hardware response to unexpected inputs), the kernel will usually
> > +attempt to implement reasonable mitigations. These are best-effort measures
> > +intended to reduce the attack surface or elevate the cost of an attack within
> > +the limits of the hardware's facilities; they do not constitute a
> > +kernel-provided safety guarantee.
> 
> "best-effort measures" and "they do not constitute a kernel-provided safety
> guarantee" can be interpreted so: if someone finds yet another Meltdown-like
> side-channel CPU bug, then this is not security bug, and should be
> reported openly. I don't think this is what you meant.

Again, please be reasonable.  Hardware bugs have their own reporting
process that we have well documented.

> > +    affect the system's availability (shutdown, reboot, panic, hang, or making
> > +    the system unresponsive via unbounded resource exhaustion).
> 
> So if unprivileged process can crash system, then this is security bug?

Yes.

> Also I'm not sure "unbounded resource exhaustion" is correct here.

Why not?

> As well as I understand, by default kernel and distros don't set any
> memory limits or limits for number of processes for unprivileged processes,
> so unprivileged process can easily cause resource exhaustion by
> allocating a lot of memory or by fork bomb.

That's a distro problem, not a kernel problem.

> So, I think you should instead say that unprivileged process, which
> has memory limit (and other limits) set using cgroups, should not
> be able to cause resource exhaustion.

Patches are always gladly accepted.  But again, be reasonable please,
this isn't a legal document :)

> > +are designed to be accessible to regular local users with a low risk (e.g.
> > +kernel logs via ``/proc/kmsg``), some would expose enough information to
> 
> /proc/kmsg has rights "-r--------", so I think there is error here.
> 
> ---------------
> 
> Finally, I have questions:
> 
> - If unprivileged user created process, which is impossible to kill
> by privileged process, is this security bug?

Sounds like a bug, we can deal with it that way.

> - If unprivileged user prevents privileged user from suspending
> system, is this security bug?

Physical access of suspending a machine feels like an odd threat model
to be worried about :)

If you have bugs that you feel are security issues like the above,
great, please report them and we can take them on a case-by-case basis.

This document is meant as a starting point for that, and to help remove
a huge number of "this is a security bug!" reports that we keep getting
that are obviously not that.

thanks,

greg k-h