| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <87shqjo13v.fsf@miraculix.mork.no>
Date: Tue, 22 Nov 2016 18:50:28 +0100
From: Bjørn Mork <bjorn@...k.no>
To: Wim Osterholt <wim@....tudelft.nl>
Cc: Oliver Neukum <oneukum@...e.com>,
poma <pomidorabelisima@...il.com>, linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org
Subject: Re: crash by cdc_acm driver in kernels 4.8-rc1/5
Wim Osterholt <wim@....tudelft.nl> writes:
> On Mon, Nov 21, 2016 at 02:19:32PM +0100, Oliver Neukum wrote:
>> On Thu, 2016-11-17 at 17:11 +0100, Wim Osterholt wrote:
>>
>> > Nov 17 15:07:51 localhost kernel: Check point 10
>> > Nov 17 15:07:51 localhost kernel: BUG: unable to handle kernel NULL pointer dereference at 00000249
>> > Nov 17 15:07:51 localhost kernel: IP: [<e186ece2>] acm_probe+0x559/0xe53 [cdc_acm]
>> > Nov 17 15:07:51 localhost kernel: *pde = 00000000
>> > Nov 17 15:07:51 localhost kernel: Oops: 0000 [#1] SMP
>>
>> I don't understand it, bit please test the attached patch
>> with dynamic debugging for cdc-acm and the kernel log level
>> at maximum. And please repost "lsusb -v" for your device.
>
> I didn't find traces of kernel-4.9-rc5 being ran on any of my laptops, so I
> can't have seen a crash on rc5. It seems rc5 and rc6 is safe now.
>
> I assume you want this on a crashing kernel, but I already removed the
> sources. (Lack of space).
> 4.8.10 is now compiling, that was the fastest option. If that one doesn't
> crash anymore I'll dig up 4.8.8 again.
>
> lsusb -v:
>
> Bus 004 Device 002: ID 0572:1340 Conexant Systems (Rockwell), Inc.
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 1.10
> bDeviceClass 2 Communications
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> idVendor 0x0572 Conexant Systems (Rockwell), Inc.
> idProduct 0x1340
> bcdDevice 1.00
> iManufacturer 1 Conexant
> iProduct 2 USB Modem
> iSerial 3 12345678
> bNumConfigurations 2
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 73
> bNumInterfaces 2
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0x80
> (Bus Powered)
> MaxPower 100mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 1
> bInterfaceClass 2 Communications
> bInterfaceSubClass 2 Abstract (modem)
> bInterfaceProtocol 1 AT-commands (v.25ter)
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 128
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 10 CDC Data
> bInterfaceSubClass 0 Unused
> bInterfaceProtocol 0
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02 EP 2 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> CDC Header:
> bcdCDC 1.10
> CDC Call Management:
> bmCapabilities 0x03
> call management
> use DataInterface
> bDataInterface 1
> CDC ACM:
> bmCapabilities 0x07
> sends break
> line coding and serial state
> get/set/clear comm features
> CDC Union:
> bMasterInterface 0
> bSlaveInterface 1
> Country Selection:
> iCountryCodeRelDate 4 04052004
> wCountryCode 0x4803
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 96
> bNumInterfaces 3
> bConfigurationValue 2
> iConfiguration 0
> bmAttributes 0x80
> (Bus Powered)
> MaxPower 100mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 1
> bInterfaceClass 2 Communications
> bInterfaceSubClass 2 Abstract (modem)
> bInterfaceProtocol 1 AT-commands (v.25ter)
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 128
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 10 CDC Data
> bInterfaceSubClass 0 Unused
> bInterfaceProtocol 0
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 10
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02 EP 2 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 10
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 2
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 10 CDC Data
> bInterfaceSubClass 0 Unused
> bInterfaceProtocol 0
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> CDC Header:
> bcdCDC 1.10
> CDC Call Management:
> bmCapabilities 0x03
> call management
> use DataInterface
> bDataInterface 1
> CDC ACM:
> bmCapabilities 0x07
> sends break
> line coding and serial state
> get/set/clear comm features
> CDC Union:
> bMasterInterface 0
> bSlaveInterface 1
> Country Selection:
> iCountryCodeRelDate 4 04052004
> wCountryCode 0x4803
No excuse for crashing of course, but that's one of the sickets
descriptor sets I've seen today. Who got the bright idea to put the
communication class functional descriptors on the data class interfaces?
And what's with the second data interface? How is the host supposed to
make any use of that when both(!) the CDC Union descriptors refer to
interface 0 and 1 only? Not that we can use those union descriptors for
much anyway since we have to guess the relationship between control and
data interface before we can get to it...
So I'm not surprised that this is unexpected by the driver. We just
need to figure out how to ignore the noise and carry on.
But looking at the driver, it looks like that is exactly what it should
do. This device has the NO_UNION_NORMAL quirk so normal probing is
skipped and we will just use interfaces 0 and 1. Which is the only sane
thing to do given the above mess...
Don't understand how it could crash.
Bjørn
Powered by blists - more mailing lists