public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Remski <mremski@mutualink.net>
To: Johan Hovold <jhovold@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: ftdi_sio BUG: NULL pointer dereference
Date: Mon, 02 Jun 2014 13:11:37 -0400	[thread overview]
Message-ID: <538CB049.9020805@mutualink.net> (raw)
In-Reply-To: <20140602164957.GC13790@localhost>

On 06/02/2014 12:49 PM, Johan Hovold wrote:
> On Mon, Jun 02, 2014 at 12:24:44PM -0400, Mike Remski wrote:
>> 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:
>>>> 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.  :)
> Not just their own ID's it seems.
>
> Have you tried just using the cdc-acm driver? The ports should up as
> /dev/ttyACMx instead of ttyUSBx.
>
> Johan
Not yet, next on the list.

I'm suspecting that bNumEndpoints == 0 is causing endpoint[1].desc to 
stay at NULL (line 1567 in 3.1.4.5 source), so by the time it gets used 
later on, I'm hitting the NULL dereference.



Thanks.

-- 
Office: (978)401-4032 (x123 internally)
Cell: (603) 759-6953


  reply	other threads:[~2014-06-02 17:11 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-02 14:25 ftdi_sio BUG: NULL pointer dereference Mike Remski
2014-06-02 14:33 ` Johan Hovold
2014-06-02 15:16   ` Mike Remski
2014-06-02 15:40     ` Johan Hovold
2014-06-02 16:02       ` Mike Remski
2014-06-02 16:20         ` Johan Hovold
2014-06-02 16:24           ` Mike Remski
2014-06-02 16:49             ` Johan Hovold
2014-06-02 17:11               ` Mike Remski [this message]
2014-06-02 17:46                 ` Johan Hovold
2014-06-02 17:50                   ` Mike Remski
2014-06-03 10:17                   ` Mike Remski
2014-06-04 14:19                     ` Johan Hovold
2014-06-04 14:29                       ` Mike Remski
2014-06-04 14:52                         ` Johan Hovold
2014-06-04 14:54                           ` Mike Remski
2014-06-04 14:55                           ` Mike Remski
2014-06-04 15:09                             ` Johan Hovold
2014-06-04 15:12                               ` Mike Remski
2014-06-04 15:41                               ` Mike Remski
2014-06-04 16:00                                 ` Johan Hovold
2014-06-04 16:13                                   ` Mike Remski
2014-06-04 17:05                                   ` Mike Remski
2014-06-05  7:10                                     ` Johan Hovold
2014-06-02 16:09       ` Mike Remski
2014-06-02 16:23         ` Greg KH
2014-06-02 16:26           ` Mike Remski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=538CB049.9020805@mutualink.net \
    --to=mremski@mutualink.net \
    --cc=jhovold@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox