On Tue, Jun 09, 2026 at 11:33:05AM +0300, Askar Safin wrote: > Willy Tarreau <[email protected]>: > > +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
