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/[email protected]/ > 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
