Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices

[Marcus Meissner <meissner () suse de>]

On Thu, Aug 18, 2016 at 04:57:24PM +0200, Greg KH wrote:
> On Thu, Aug 18, 2016 at 04:39:57PM +0200, Marcus Meissner wrote:
> > On Thu, Aug 18, 2016 at 04:30:14PM +0200, Greg KH wrote:
> > > On Thu, Aug 18, 2016 at 04:22:16PM +0200, Marcus Meissner wrote:
> > > > Hi,
> > > >
> > > > I think this does not have a CVE yet, please assign.
> > > >
> > > > https://www.spinics.net/lists/linux-usb/msg144177.html
> > > >
> > > > Headline:         Linux Kernel Panic Over USB with HID Keyboard wMaxPacketSize
> > > > Platforms:        Ubuntu
> > > > Versions:         Linux Kernel 4.4.0-22-generic
> > >
> > > Huh?  It's much more pervasive than just that single platform or single
> > > version.
> >
> > That was the quote from the original e-mail. I read further on it affects
> > more kernel versions.
> >  
> > > > CVSS Score:       4.7
> > > > CVSS Vector:      AV:L/AC:M/Au:N/C:N/I:N/A:C
> > > > Filed Defects:    
> > > > Related Defects:  
> > > > CWE Tags:         
> > > > Cycle:            
> > > > Found by:         Jake Lamberson
> > > >
> > > >
> > > > Linux Kernel panics when using an OHCI controller if a USB device reports being 
> > > > a generic HID keyboard and reports a wMaxPacketSize of over 4095. The OHCI
> > > > controller driver fails to reserve bandwidth for the device, causing the 
> > > > keyboard handler to fail when attaching to the HID. Later, when the device is 
> > > > removed, the system crashes due to a null pointer dereference in a linked list 
> > > > of endpoint descriptors. The crash can be re-created using a Facedancer and UMAP 
> > > > software. Given an appropriately configured Facedancer and UMAP setup, the crash 
> > > > can be re-created with: 
> > > > sudo board=facedancer21 python3 umap.py -P /dev/serial_device_here -f 03:00:00:E:0046 -l LOG
> > > >
> > > > Note: OHCI is a USB 1.1 controller standard that can be included with devices
> > > > that support either USB 1.1 or 2.0 as their highest USB spec. USB 3.0 devices
> > > > all use xHCI, which implements USB 1.1, 2.0, and 3.0, making them immune to
> > > > this particular bug.
> > > >
> > > > -----------------
> > > >
> > > > The proposed fixing patch is here:
> > > > https://www.spinics.net/lists/linux-usb/msg144269.html
> > > >
> > > >
> > > > It has not yet been committed to the USB tree or to Linus Tree as far as I see.
> > >
> > > Not true, it is commit id aed9d65ac3278d4febd8665bd7db59ef53e825fe in
> > > the usb tree and in linux-next and will be sent to Linus tomorrow.
> >
> > Ah sorry, only looked briefly.
>
> This was also asked about 2 hours ago on the linux-usb mailing list, why
> all of the sudden interest in something that we had been discussing for
> weeks now in public?

No one asked for a CVE before.

If that email request was from Oliver Neukum, he pinged me on it, so I
started acting on it, so that explains this parallelism.
 
> > > And are we really assigning CVE numbers for when you use an active
> > > "hardware test probe"?  If so, how many are people going to be assigning
> > > for these same problems on other operating systems?  :)
> >
> > I think attaching malicious USB devices and crashing the kernel should
> > probably get CVE ids, or do you think it should not?
>
> I don't know, that's why I'm asking, it requires "physical presence"
> which is much different from most threat models that people work to
> protect against.

There has been quite a number of CVEs assigned to malicious USB devices
this year already, this does not seem to be different.

(e.g. CVE-2016-2384, CVE-2016-2188, CVE-2016-2187 etc.)

Ciao, Marcus