Re: Stack buffer overflow (write) in kvaser_usb_leaf_wait_cmd via malicious USB

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Feb 24, 2026 at 01:43:24PM -0500, Alan Stern wrote:
> On Tue, Feb 24, 2026 at 05:04:28PM +0100, Oliver Neukum wrote:
> > 
> > 
> > On 24.02.26 16:52, Alan Stern wrote:
> > > On Tue, Feb 24, 2026 at 09:44:35AM +0100, Oliver Neukum wrote:
> > 
> > > > What is the logic behind that? If we can trust that a device
> > > > is what it claims to be and operates like it is supposed to
> > > > be, why do we verify?
> > > 
> > > Greg said that we trust the hardware once a driver is bound to the
> > > device.  However, the endpoint-verification tests occur before the
> > > binding is complete.  At this point we do not yet fully trust the
> > > hardware.
> > 
> > Why? If we do not trust the hardware, we cannot depend on it
> > telling the truth about itself, can we?
> 
> The purpose of the endpoint testing is to avoid warnings triggered by 
> driver submitting URBs to endpoints that are known not to exist.  Such 
> submissions are generally considered to be signs of a bug in the driver, 
> not of a deception by the device.
> 
> Legitimate example: A new revision of a device uses different endpoint 
> numbers from the original version, but the driver isn't aware of this 
> and doesn't check.  The problem would then lie in the driver, not in the 
> revised device firmware.
> 
> Even if a device lies about itself, the tests will prevent these 
> warnings from triggering.  (The endpoint in question might not in fact 
> exist on the device, but as long as the device's descriptors claim that 
> the endpoint does exist, usbcore won't know any better and so won't 
> issue a warning.)
> 
> Of course we can't detect all cases in which a device lies about itself.  
> The hope is that drivers will be robust enough to handle devices that do 
> not behave as expected...
> 
> > > While it's always possible that some real device somewhere will fail
> > > these tests, a much more likely reason for a failure is because the
> > > driver is being fuzzed.  We do know that these fuzzing tests occur in
> > > real life and that they will crash the kernel being tested if the tests
> > > aren't present.
> > 
> > Now, if we are looking at regular hardware, we need to ask ourselves:
> > Is it likelier that some devices are different from all others,
> > or may they have a race condition with a small window that leads
> > to faulty data packages rarely being generated?
> 
> ... such as by occasionally generating faulty data packets.  Drivers 
> should be able to handle such things gracefully, without crashing the 
> kernel.

Given that I have to answer this type of question about every other week
these days given the fuzzing reports we get sent to the
security@kernel.org alias, I think I need to just write up a "here is
the Linux USB threat model that we currently support" document to
describe what the state is.

We can then work from there, either agreeing that we need to "move" the
level of interaction for which we trust / do not trust a device in the
lifecycle of a USB device, or just be happy with where it currently is.

That should work better with some groups that I know are working to do
stuff to "harden" the USB device stack for some specific use cases,
hopefully just using the existing user api that we have today that
USBGuard uses, or possibly adding to that to handle some missing areas
that we have not previously considered.

thanks,

greg k-h