[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#583731: marked as done (broken usbfs support after CVE-2010-1083)



Your message dated Sat, 31 Jul 2010 22:07:28 -0400
with message-id <20100801020728.GA11103@galadriel.inutil.org>
and subject line Re: Bug Traced to Application Code
has caused the Debian Bug report #583731,
regarding broken usbfs support after CVE-2010-1083
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
583731: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583731
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: libusb
Version: 2:0.1.12-1

I have encountered problems with a program that uses libusb-0.1-4 ever since installing the lenny1 security update of linux-image-2.6.26-2-686.

Perhaps it is a regression in the kernel related to CVE-2010-1083??

I am not sure whether the bug report should belong to the kernel or libusb, or maybe its a fault in the program I use (although it worked well before the kernel upgrade).

A partial strace follows:

open("/dev/bus/usb/002/002", O_RDWR)    = 3
rt_sigaction(SIGTERM, {0x8048c64, [TERM], SA_RESTART}, {SIG_DFL}, 8) = 0
ioctl(3, USBDEVFS_GETDRIVER, 0xbfffe788) = -1 ENODATA (No data available)
ioctl(3, USBDEVFS_CLAIMINTERFACE, 0xbfffe8a4) = 0
ioctl(3, USBDEVFS_SETINTERFACE, 0xbfffe884) = 0
ioctl(3, USBDEVFS_CONTROL, 0xbfffe44c)  = 18
ioctl(3, USBDEVFS_CONTROL, 0xbfffe44c)  = 9
ioctl(3, USBDEVFS_CONTROL, 0xbfffe44c)  = 34
ioctl(3, USBDEVFS_RELEASEINTERFACE, 0xbfffe4b4) = 0
ioctl(3, USBDEVFS_SETCONFIGURATION, 0xbfffe4b4) = 0
ioctl(3, USBDEVFS_CLAIMINTERFACE, 0xbfffe4b4) = 0
ioctl(3, USBDEVFS_SETINTERFACE, 0xbfffe494) = 0
ioctl(3, USBDEVFS_CONTROL, 0xbfffe48c)  = 0
ioctl(3, USBDEVFS_CONTROL, 0xbfffe44c)  = 59
ioctl(3, USBDEVFS_CONTROL, 0xbfffe48c)  = 8
gettimeofday({1275206696, 628403}, NULL) = 0
ioctl(3, USBDEVFS_SUBMITURB, 0xbfffe464) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbfffe4a8) = -1 EAGAIN (Resource temporarily unavailable)
select(4, NULL, [3], NULL, {0, 1000})   = 0 (Timeout)
gettimeofday({1275206696, 630976}, NULL) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbfffe4a8) = -1 EAGAIN (Resource temporarily unavailable)
select(4, NULL, [3], NULL, {0, 1000})   = 0 (Timeout)

The USBDEVFS_REAPURBNDELAY -> EAGAIN / select / gettimeofday sequence happens about 350 times and then the program prints rubbish data.

Kernel: Linux 2.6.26-2-686 #1 SMP Wed May 12 21:56:10 UTC 2010 i686 GNU/Linux
Libc6: 2.7-18lenny2

Details of the USB device (which is a Chinese weather station not a Dream Link USB Missile Launcher):

Bus 002 Device 002: ID 1941:8021 Dream Link USB Missile Launcher
Device Descriptor:
 bLength                18
 bDescriptorType         1
 bcdUSB               1.10
 bDeviceClass            0 (Defined at Interface level)
bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8
 idVendor           0x1941 Dream Link
 idProduct          0x8021 USB Missile Launcher
 bcdDevice            1.00
iManufacturer 0 iProduct 0 iSerial 0 bNumConfigurations 1
 Configuration Descriptor:
   bLength                 9
   bDescriptorType         2
   wTotalLength           34
   bNumInterfaces          1
   bConfigurationValue     1
iConfiguration 0 bmAttributes 0x80
     (Bus Powered)
   MaxPower              100mA
   Interface Descriptor:
     bLength                 9
     bDescriptorType         4
     bInterfaceNumber        0
     bAlternateSetting       0
     bNumEndpoints           1
     bInterfaceClass         3 Human Interface Device
     bInterfaceSubClass      0 No Subclass
     bInterfaceProtocol      0 None
iInterface 0 HID Device Descriptor:
         bLength                 9
         bDescriptorType        33
         bcdHID               1.00
         bCountryCode            0 Not supported
         bNumDescriptors         1
         bDescriptorType        34 Report
         wDescriptorLength      52
         Report Descriptor: (length is 52)
           Item(Global): Usage Page, data= [ 0xa0 0xff ] 65440
                           (null)
           Item(Local ): Usage, data= [ 0x01 ] 1
                           (null)
           Item(Main  ): Collection, data= [ 0x01 ] 1
                           Application
           Item(Local ): Usage, data= [ 0x02 ] 2
                           (null)
           Item(Main  ): Collection, data= [ 0x00 ] 0
                           Physical
           Item(Global): Usage Page, data= [ 0xa1 0xff ] 65441
                           (null)
           Item(Local ): Usage Minimum, data= [ 0x01 ] 1
                           (null)
           Item(Local ): Usage Maximum, data= [ 0x08 ] 8
                           (null)
           Item(Global): Logical Minimum, data= [ 0x80 ] 128
           Item(Global): Logical Maximum, data= [ 0x7f ] 127
           Item(Global): Physical Minimum, data= [ 0x00 ] 0
           Item(Global): Physical Maximum, data= [ 0xff ] 255
           Item(Global): Report Size, data= [ 0x08 ] 8
           Item(Global): Report Count, data= [ 0x08 ] 8
           Item(Main  ): Input, data= [ 0x02 ] 2
                           Data Variable Absolute No_Wrap Linear
                           Preferred_State No_Null_Position Non_Volatile Bitfield
           Item(Local ): Usage Minimum, data= [ 0x11 ] 17
                           (null)
           Item(Local ): Usage Maximum, data= [ 0x18 ] 24
                           (null)
           Item(Global): Logical Minimum, data= [ 0x80 ] 128
           Item(Global): Logical Maximum, data= [ 0x7f ] 127
           Item(Global): Physical Minimum, data= [ 0x00 ] 0
           Item(Global): Physical Maximum, data= [ 0xff ] 255
           Item(Global): Report Size, data= [ 0x08 ] 8
           Item(Global): Report Count, data= [ 0x08 ] 8
           Item(Main  ): Output, data= [ 0x02 ] 2
                           Data Variable Absolute No_Wrap Linear
                           Preferred_State No_Null_Position Non_Volatile Bitfield
           Item(Main  ): End Collection, data=none
           Item(Main  ): End Collection, data=none
     Endpoint Descriptor:
       bLength                 7
       bDescriptorType         5
       bEndpointAddress     0x81  EP 1 IN
       bmAttributes            3
         Transfer Type            Interrupt
         Synch Type               None
         Usage Type               Data
       wMaxPacketSize     0x0008  1x 8 bytes
       bInterval              10
Device Status:     0x0000
 (Bus Powered)


Many thanks for your consideration,
 David






--- End Message ---
--- Begin Message ---
On Sun, Aug 01, 2010 at 11:11:35AM +1000, David Brodrick wrote:
> I traced the change of behaviour when changing kernel versions to a
> problem in the application itself.
> 
> One of the usb_control_msg calls was being made with data that the
> device did not understand, and so the device was not responding and
> usb_interrupt_read was returning an error status that the developer
> (not me :-) never checked.
> 
> It is kind of amazing it ever worked, but the response buffer
> contained valid data from a previous usb call, however the patches
> to the kernel changed the contents of the buffer which 'broke' the
> broken application.
> 
> I updated the application code to fix the arguments to the
> usb_control_msg call so that device responded correctly and to check
> the return status of all of the usb calls and the application has
> now been verified to work properly on 2.6.26-21lenny4,
> 2.6.26-22lenny1, 2.6.32-5, 2.6.32-trunk and a 2.6.34 kernel.
> 
> Apologies for not having a much deeper dig into this at the start.

Ok, closing the bug, then.

Cheers,
        Moritz


--- End Message ---

Reply to: