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

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

On Sat, May 02, 2026 at 01:51:08AM -0400, Demi Marie Obenour wrote:
> On 5/2/26 01:35, Willy Tarreau wrote:
> > Hi Demi Marie,
> > 
> > On Sat, May 02, 2026 at 01:20:10AM -0400, Demi Marie Obenour wrote:
> >>>>> 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.
> >> FYI, I don't think this is limited to Android.  Chrome OS definitely
> >> cares about malicious USB devices, and the whole purpose of USBGuard is
> >> to prevent a USB device from being able to compromise the system unless
> >> authorized.  I believe Qubes OS also cares, as it supports USB device
> >> assignment to virtual machines.  CCing qubes-devel for confirmation.
> >>
> >> What should that patch look like?  Could there be a way for these user
> >> groups to be informed of vulnerabilities in the USB subsystem, so that
> >> they can take responsibility for fixing them before they become public?
> > 
> > I've posted a proposal elsewhere in the same thread:
> > 
> >    https://lore.kernel.org/lkml/afSxSX8RK0Z4kkOI@1wt.eu/
> 
> I saw that, but it's still not quite clear what is meant here.
> My understanding is that those concerned about malicious USB devices
> are generally concerned about _arbitrary_ malicious USB devices.
> The one thing a USB device shouldn't be able to spoof is the port
> it is plugged into, and userspace tools like USBGuard can use that
> information.  But to do that, they have to trust that the device
> can't harm the system if it isn't assigned to any drivers.

The goal sought by that early document precisely is to draw the line
between what is a regular bug and hwat is a kernel bug. The kernel
currently doesn't consider problems posed by a crafted USB device as a
security issue because the kernel trusts the hardware in runs on. Of
course there can be valid reasons to disagree with this, but it's just
the current situation and the purpose of the document is to clarify it
so that bugs are reported to the right place and handled efficiently.

> >> It does make sense for those who care about the security of a subsystem
> >> to be responsible for vulnerabilities in that system, but right now
> >> I'm not sure how one would offer to take up that responsibility.
> > 
> > I think that at least some subsystems will want to add their own
> > restrictions based on the bug reports they keep receiving, and I hope
> > it can help distros figure where there's a gap between is promised to
> > users and what the kernel promises, that needs to be filled by userland
> > verification tools for example.
> > 
> > Willy
> 
> I think there might be another category, which is were there is a
> third party who is much more interested in the security of a subsystem
> than its primary maintainers are.  I suspect that Google is said
> third party in multiple such cases, especially various USB drivers.
> In particular, exploiting the kernel via USB is a common attack
> technique used in the wild by tools like Cellebrite.

Possibly that such ones might appear there at some point. The best
way for these might be to have such teams try to step up as
co-maintainers for the parts they care about though.

> In these cases, I think it makes sense to funnel vulnerability
> reports to the people who actually seriously care about fixing them.
> For instance, problems in USB might be funneled to the Chrome OS and
> Android security teams.  They will get fixed much more quickly, and
> upstream maintainers won't be flooded with reports that don't have
> attached patches.

Trust me, patches written behind closed doors rarely resist publication
and discovery by the maintainer. And treating bugs as regular ones in
fact tends to make them move faster than as security ones. No need to
go back-and-forth asking for data that reporters hesitate to share, nor
to have to first convince them that their bug needs to be fixed even
though they were planning on speaking about them at a conference, etc.

Cheers,
Willy