| 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: <538CA54C.4040803@mutualink.net> Date: Mon, 02 Jun 2014 12:24:44 -0400 From: Mike Remski <mremski@...ualink.net> To: Johan Hovold <jhovold@...il.com> CC: linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org Subject: Re: ftdi_sio BUG: NULL pointer dereference On 06/02/2014 12:20 PM, Johan Hovold wrote: > 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 Johan, Thanks again. Yes, the device does indeed have an FTDI embedded in it; they've programmed in their own ids. They supply a Windows driver for it, but that doesn't do me any good. :) I will work on getting a later version set up for testing. May not happen today but as soon as possible. -- Office: (978)401-4032 (x123 internally) Cell: (603) 759-6953 -- 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