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

[Willy Tarreau <w@1wt.eu>]

On Tue, Apr 28, 2026 at 03:13:01PM -0600, Greg KH wrote:
> > > We can point at other files, as this list is going to get long over
> > > time, which is a good thing.
> > 
> > Sure. I'm just unsure where this could be enumerated, as it's likely
> > that there would be just one or two lines max per subsystem for the
> > majority of them. Or we could have a totally separate file, "threat
> > model", that goes into great lengths detailing all this with sections
> > per category or subsystem when they start to grow maybe, and refer only
> > to that one from security-bugs ?
> 
> I think a separate file is good, I know I need to write up what the USB
> model is, and it's different from PCI, and different from other
> subsystems.  All should probably be documented eventually.

Would you be interested in me trying to initiate a new "threat-model.rst"
file that tries to unroll the points mentioned in the list ? I'm concerned
that that withuot having many details initially, it could look a bit odd,
because the list we currently have would be more suitable for an "other"
section.

> > > > > (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".
> > > 
> > > Ah, but USB does cover "some" modification of devices, so this is going
> > > to be something that is good to document over time, if for no other
> > > reason to keep these scanning tools in check from hallucinating crazy
> > > situations that are obviously not a valid thing we care about.
> > 
> > OK but does this mean you still want to get these reports in the end ?
> 
> I want a patch if a user cares about that threat-model (as Android does
> but no one else) as it's up to the user groups that want to change the
> default kernel's behavior like this to actually submit patches to do so.

Yes, OK, but we want them in any case. That's the idea I tried to convey
in the proposed doc (maybe not well enough), basically "this is a bug and
it is worth reporting, but no need to involve s@k.o for this".

thanks,
Willy