| 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
| ||
|
Date: Mon, 2 Jun 2014 18:20:27 +0200 From: Johan Hovold <jhovold@...il.com> To: Mike Remski <mremski@...ualink.net> Cc: Johan Hovold <jhovold@...il.com>, linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org Subject: Re: ftdi_sio BUG: NULL pointer dereference On Mon, Jun 02, 2014 at 12:02:40PM -0400, Mike Remski wrote: > On 06/02/2014 11:40 AM, Johan Hovold wrote: > > [ Please avoid top-posting. ] > > > > On Mon, Jun 02, 2014 at 11:16:11AM -0400, Mike Remski wrote: > >> Thanks Johan, that's why I looked at the cross references for ftdi_sio.c > >> over on > >> http://lxr.free-electrons.com/source/drivers/usb/serial/ftdi_sio.c, > >> latest version it's showing is 3.14. It appears that the ftdi_sio code > >> is largely the same as in 2.6.32, particularly in the > >> ftdi_set_max_packet_size() function. > > Lots of things have changed since v2.6.32 and not just in the driver > > itself but in all the infrastructure it relies on. > > > >> I'm trying to verify if the "number of endpoints is 0" is a valid > >> situation. > > No, that is not normal, but it should not crash the driver if it's a > > hardware issue. What is the lsusb -v output of your device (make sure > > the ftdi_sio driver isn't loaded when connecting the device). > > > > And what happens if you plug it into a machine running a recent kernel? > > > > Thanks, > > Johan > Thanks Johan; sorry for top posting. > An even more ancient kernel (2.6.18) has v1.4.3 of the ftdi_sio.c and I > do not see this problem. In v1.4.3, > ftdi_sio_attach() is doing the work that is now in > ftdi_sio_port_probe(), but 1.4.3 does not have the > ftdi_set_max_packet_size() code. The device works fine under 2.6.18. I > have to see if I can scrounge up > a machine running a later kernel (other than my desktop). Your desktop should be just fine for testing. > Should have included this earlier but its unmodified CentOs 6.0 and 6.4, > kernel is: > > Linux nicA91A84 2.6.32-71.29.1.el6.i686 #1 SMP Tue May 10 17:35:05 CDT > 2011 i686 i686 i386 GNU/Linux > > > lsusb -v cut for the device in question. > > Bus 005 Device 003: ID 1fdf:1001 > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 239 Miscellaneous Device > bDeviceSubClass 2 ? > bDeviceProtocol 1 Interface Association > bMaxPacketSize0 64 > idVendor 0x1fdf > idProduct 0x1001 > bcdDevice 0.03 > iManufacturer 1 Sepura > iProduct 2 Colour Console > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 134 > bNumInterfaces 4 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xc0 > Self Powered > MaxPower 100mA > Interface Association: > bLength 8 > bDescriptorType 11 > bFirstInterface 0 > bInterfaceCount 2 > bFunctionClass 2 Communications > bFunctionSubClass 2 Abstract (modem) Is this indeed the right device? Then you seem to be using the wrong driver as this is no FTDI device, but a CDC-ACM modem-class device which should be driven by the cdc-acm driver. > bFunctionProtocol 0 None > iFunction 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 2 Communications > bInterfaceSubClass 2 Abstract (modem) > bInterfaceProtocol 0 None > iInterface 0 > CDC Header: > bcdCDC 1.10 > CDC Call Management: > bmCapabilities 0x01 > call management > bDataInterface 1 > CDC ACM: > bmCapabilities 0x02 > line coding and serial state > CDC Union: > bMasterInterface 0 > bSlaveInterface 1 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x83 EP 3 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 10 > 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 0x01 EP 1 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 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 0 > Interface Association: > bLength 8 > bDescriptorType 11 > bFirstInterface 2 > bInterfaceCount 2 > bFunctionClass 2 Communications > bFunctionSubClass 2 Abstract (modem) > bFunctionProtocol 0 None > iFunction 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 2 > bAlternateSetting 0 > bNumEndpoints 0 The third interface lacks endpoints and crashes the ftdi_sio driver. This shouldn't happen (even if you're forcing the wrong driver to bind), so I'll fix it up if still broken in v3.15-rc. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists