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

[Greg KH <greg@kroah.com>]

On Wed, Apr 29, 2026 at 05:09:43AM +0200, Willy Tarreau wrote:
> 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.

Sure, a small file to start with would be good for people to work off
of and add to.

> > > > > > (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".

Yes, you conveyed that, sorry if I insinuated otherwise.

thanks,

greg k-h