linux-stable.git/drivers/usb, branch linux-2.6.37.y

USB: cdc-acm: fix potential null-pointer dereference on disconnect

2011-03-27T19:00:30+00:00

commit 7e7797e7f6f7bfab73fca02c65e40eaa5bb9000c upstream.

Fix potential null-pointer exception on disconnect introduced by commit
11ea859d64b69a747d6b060b9ed1520eab1161fe (USB: additional power savings
for cdc-acm devices that support remote wakeup).

Only access acm->dev after making sure it is non-null in control urb
completion handler.

Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: cdc-acm: fix potential null-pointer dereference

2011-03-27T19:00:29+00:00

commit 15e5bee33ffc11d0e5c6f819a65e7881c5c407be upstream.

Must check return value of tty_port_tty_get.

Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: cdc-acm: fix memory corruption / panic

2011-03-27T19:00:28+00:00

commit 23b80550e2aa61d0ba3af98b831b9195be0db9ee upstream.

Prevent read urbs from being resubmitted from tasklet after port close.

The receive tasklet was not disabled on port close, which could lead to
corruption of receive lists on consecutive port open. In particular,
read urbs could be re-submitted before port open, added to free list in
open, and then added a second time to the free list in the completion
handler.

cdc-acm.c: Entering acm_tty_open.
cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x3 len: 0x0 result: 0
cdc-acm.c: Entering acm_rx_tasklet
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da280, rcv 0xf57fbc24, buf 0xf57fbd64
cdc-acm.c: set line: 115200 0 0 8
cdc-acm.c: acm_control_msg: rq: 0x20 val: 0x0 len: 0x7 result: 7
cdc-acm.c: acm_tty_close
cdc-acm.c: acm_port_down
cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x0 len: 0x0 result: 0
cdc-acm.c: acm_ctrl_irq - urb shutting down with status: -2
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da300, rcv 0xf57fbc10, buf 0xf57fbd50
cdc-acm.c: Entering acm_read_bulk with status -2
cdc_acm 4-1:1.1: Aborting, acm not ready
cdc-acm.c: Entering acm_read_bulk with status -2
cdc_acm 4-1:1.1: Aborting, acm not ready
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da380, rcv 0xf57fbbfc, buf 0xf57fbd3c
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da400, rcv 0xf57fbbe8, buf 0xf57fbd28
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da480, rcv 0xf57fbbd4, buf 0xf57fbd14
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da900, rcv 0xf57fbbc0, buf 0xf57fbd00
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da980, rcv 0xf57fbbac, buf 0xf57fbcec
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50daa00, rcv 0xf57fbb98, buf 0xf57fbcd8
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50daa80, rcv 0xf57fbb84, buf 0xf57fbcc4
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dab00, rcv 0xf57fbb70, buf 0xf57fbcb0
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dab80, rcv 0xf57fbb5c, buf 0xf57fbc9c
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dac00, rcv 0xf57fbb48, buf 0xf57fbc88
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dac80, rcv 0xf57fbb34, buf 0xf57fbc74
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dad00, rcv 0xf57fbb20, buf 0xf57fbc60
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dad80, rcv 0xf57fbb0c, buf 0xf57fbc4c
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da880, rcv 0xf57fbaf8, buf 0xf57fbc38
cdc-acm.c: Entering acm_tty_open.
cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x3 len: 0x0 result: 0
cdc-acm.c: Entering acm_rx_tasklet
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da280, rcv 0xf57fbc24, buf 0xf57fbd64
cdc-acm.c: Entering acm_tty_write to write 3 bytes,
cdc-acm.c: Get 3 bytes...
cdc-acm.c: acm_write_start susp_count: 0
cdc-acm.c: Entering acm_read_bulk with status 0
------------[ cut here ]------------
WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:57 list_del+0x10c/0x120()
Hardware name: Vostro 1520
list_del corruption. next->prev should be f57fbc10, but was f57fbaf8
Modules linked in: cdc_acm
Pid: 3, comm: ksoftirqd/0 Not tainted 2.6.37+ #39
Call Trace:
 [] warn_slowpath_common+0x72/0xa0
 [] ? list_del+0x10c/0x120
 [] ? list_del+0x10c/0x120
 [] warn_slowpath_fmt+0x33/0x40
 [] list_del+0x10c/0x120
 [] acm_rx_tasklet+0xef/0x3e0 [cdc_acm]
 [] ? net_rps_action_and_irq_enable+0x6d/0x80
 [] tasklet_action+0xe6/0x140
 [] __do_softirq+0xaf/0x210
 [] ? __do_softirq+0x0/0x210
   [] ? run_ksoftirqd+0x8a/0x1c0
 [] ? run_ksoftirqd+0x0/0x1c0
 [] ? kthread+0x74/0x80
 [] ? kthread+0x0/0x80
 [] ? kernel_thread_helper+0x6/0x10
---[ end trace efd9a11434f0082e ]---
------------[ cut here ]------------
WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:57 list_del+0x10c/0x120()
Hardware name: Vostro 1520
list_del corruption. next->prev should be f57fbd50, but was f57fbdb0
Modules linked in: cdc_acm
Pid: 3, comm: ksoftirqd/0 Tainted: G        W   2.6.37+ #39
Call Trace:
 [] warn_slowpath_common+0x72/0xa0
 [] ? list_del+0x10c/0x120
 [] ? list_del+0x10c/0x120
 [] warn_slowpath_fmt+0x33/0x40
 [] list_del+0x10c/0x120
 [] acm_rx_tasklet+0x106/0x3e0 [cdc_acm]
 [] ? net_rps_action_and_irq_enable+0x6d/0x80
 [] tasklet_action+0xe6/0x140
 [] __do_softirq+0xaf/0x210
 [] ? __do_softirq+0x0/0x210
   [] ? run_ksoftirqd+0x8a/0x1c0
 [] ? run_ksoftirqd+0x0/0x1c0
 [] ? kthread+0x74/0x80
 [] ? kthread+0x0/0x80
 [] ? kernel_thread_helper+0x6/0x10
---[ end trace efd9a11434f0082f ]---
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da300, rcv 0xf57fbc10, buf 0xf57fbd50
cdc-acm.c: disconnected from network
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da380, rcv 0xf57fbbfc, buf 0xf57fbd3c
cdc-acm.c: Entering acm_rx_tasklet
------------[ cut here ]------------
WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:48 list_del+0xd5/0x120()
Hardware name: Vostro 1520
list_del corruption, next is LIST_POISON1 (00100100)
Modules linked in: cdc_acm
Pid: 3, comm: ksoftirqd/0 Tainted: G        W   2.6.37+ #39
Call Trace:
 [] warn_slowpath_common+0x72/0xa0
 [] ? list_del+0xd5/0x120
 [] ? list_del+0xd5/0x120
 [] warn_slowpath_fmt+0x33/0x40
 [] list_del+0xd5/0x120
 [] acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm]
 [] ? trace_hardirqs_on+0xb/0x10
 [] ? tasklet_action+0x60/0x140
 [] tasklet_action+0xe6/0x140
 [] __do_softirq+0xaf/0x210
 [] ? __do_softirq+0x0/0x210
   [] ? run_ksoftirqd+0x8a/0x1c0
 [] ? run_ksoftirqd+0x0/0x1c0
 [] ? kthread+0x74/0x80
 [] ? kthread+0x0/0x80
 [] ? kernel_thread_helper+0x6/0x10
---[ end trace efd9a11434f00830 ]---
BUG: unable to handle kernel paging request at 00200200
IP: [] list_del+0x1d/0x120
*pde = 00000000
Oops: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/tty/ttyACM0/uevent
Modules linked in: cdc_acm
Pid: 3, comm: ksoftirqd/0 Tainted: G        W   2.6.37+ #39 0T816J/Vostro 1520
EIP: 0060:[] EFLAGS: 00010046 CPU: 0
EIP is at list_del+0x1d/0x120
EAX: f57fbd3c EBX: f57fb800 ECX: ffff8000 EDX: 00200200
ESI: f57fbe90 EDI: f57fbd3c EBP: f600bf54 ESP: f600bf3c
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process ksoftirqd/0 (pid: 3, ti=f600a000 task=f60791c0 task.ti=f6082000)
Stack:
 c1527e84 00000030 c1527e54 00100100 f57fb800 f57fbd3c f600bf98 f8051fac
 f8053104 f8052b94 f600bf6c c106dbab f600bf80 00000286 f60791c0 c1042b30
 f57fbda8 f57f5800 f57fbdb0 f57fbd80 f57fbe7c c1656b04 00000000 f600bfb0
Call Trace:
 [] ? acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm]
 [] ? trace_hardirqs_on+0xb/0x10
 [] ? tasklet_action+0x60/0x140
 [] ? tasklet_action+0xe6/0x140
 [] ? __do_softirq+0xaf/0x210
 [] ? __do_softirq+0x0/0x210
 
 [] ? run_ksoftirqd+0x8a/0x1c0
 [] ? run_ksoftirqd+0x0/0x1c0
 [] ? kthread+0x74/0x80
 [] ? kthread+0x0/0x80
 [] ? kernel_thread_helper+0x6/0x10
Code: ff 48 14 e9 57 ff ff ff 90 90 90 90 90 90 55 89 e5 83 ec 18 81 38 00 01 10 00 0f 84 9c 00 00 00 8b 50 04 81 fa 00 02 20 00 74 33 <8b> 12 39 d0 75 5c 8b 10 8b 4a 04 39 c8 0f 85 b5 00 00 00 8b 48
EIP: [] list_del+0x1d/0x120 SS:ESP 0068:f600bf3c
CR2: 0000000000200200
---[ end trace efd9a11434f00831 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Pid: 3, comm: ksoftirqd/0 Tainted: G      D W   2.6.37+ #39
Call Trace:
 [] ? printk+0x1d/0x24
 [] panic+0x66/0x15c
 [] oops_end+0x8f/0x90
 [] no_context+0xc6/0x160
 [] __bad_area_nosemaphore+0x98/0x140
 [] ? release_console_sem+0x1d8/0x210
 [] bad_area_nosemaphore+0x17/0x20
 [] do_page_fault+0x279/0x420
 [] ? show_trace+0x1f/0x30
 [] ? printk+0x1d/0x24
 [] ? do_page_fault+0x0/0x420
 [] error_code+0x5f/0x64
 [] ? select_task_rq_fair+0x37b/0x6a0
 [] ? do_page_fault+0x0/0x420
 [] ? list_del+0x1d/0x120
 [] acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm]
 [] ? trace_hardirqs_on+0xb/0x10
 [] ? tasklet_action+0x60/0x140
 [] tasklet_action+0xe6/0x140
 [] __do_softirq+0xaf/0x210
 [] ? __do_softirq+0x0/0x210
   [] ? run_ksoftirqd+0x8a/0x1c0
 [] ? run_ksoftirqd+0x0/0x1c0
 [] ? kthread+0x74/0x80
 [] ? kthread+0x0/0x80
 [] ? kernel_thread_helper+0x6/0x10
panic occurred, switching back to text console
------------[ cut here ]------------

Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: Fix 'bad dma' problem on WDM device disconnect

2011-03-27T19:00:27+00:00

commit 878b753e32ca765cd346a5d3038d630178ec78ff upstream.

In the WDM class driver a disconnect event leads to calls to
usb_free_coherent to put back two USB DMA buffers allocated earlier.
The call to usb_free_coherent uses a different size parameter
(desc->wMaxCommand) than the corresponding call to usb_alloc_coherent
(desc->bMaxPacketSize0).

When a disconnect event occurs, this leads to 'bad dma' complaints
from usb core because the USB DMA buffer is being pushed back to the
'buffer-2048' pool from which it has not been allocated.

This patch against the most recent linux-2.6 kernel ensures that the
parameters used by usb_alloc_coherent & usb_free_coherent calls in
cdc-wdm.c match.

Signed-off-by: Robert Lukassen 
Signed-off-by: Greg Kroah-Hartman

USB: uss720 fixup refcount position

2011-03-27T19:00:27+00:00

commit adaa3c6342b249548ea830fe8e02aa5b45be8688 upstream.

My testprog do a lot of bitbang - after hours i got following warning and my machine lockups:
WARNING: at /build/buildd/linux-2.6.38/lib/kref.c:34
After debugging uss720 driver i discovered that the completion callback was called before
usb_submit_urb returns. The callback frees the request structure that is krefed on return by
usb_submit_urb.

Signed-off-by: Peter Holik 
Acked-by: Thomas Sailer 
Signed-off-by: Greg Kroah-Hartman

ehci-hcd: Bug fix: don't set a QH's Halt bit

2011-03-27T19:00:26+00:00

commit b5a3b3d985493c173925907adfebf3edab236fe7 upstream.

This patch (as1453) fixes a long-standing bug in the ehci-hcd driver.

There is no need to set the Halt bit in the overlay region for an
unlinked or blocked QH.  Contrary to what the comment says, setting
the Halt bit does not cause the QH to be patched later; that decision
(made in qh_refresh()) depends only on whether the QH is currently
pointing to a valid qTD.  Likewise, setting the Halt bit does not
prevent completions from activating the QH while it is "stopped"; they
are prevented by the fact that qh_completions() temporarily changes
qh->qh_state to QH_STATE_COMPLETING.

On the other hand, there are circumstances in which the QH will be
reactivated _without_ being patched; this happens after an URB beyond
the head of the queue is unlinked.  Setting the Halt bit will then
cause the hardware to see the QH with both the Active and Halt bits
set, an invalid combination that will prevent the queue from
advancing and may even crash some controllers.

Apparently the only reason this hasn't been reported before is that
unlinking URBs from the middle of a running queue is quite uncommon.
However Test 17, recently added to the usbtest driver, does exactly
this, and it confirms the presence of the bug.

In short, there is no reason to set the Halt bit for an unlinked or
blocked QH, and there is a very good reason not to set it.  Therefore
the code that sets it is removed.

Signed-off-by: Alan Stern 
Tested-by: Andiry Xu 
CC: David Brownell 
Signed-off-by: Greg Kroah-Hartman

USB: Do not pass negative length to snoop_urb()

2011-03-27T19:00:25+00:00

commit 9d02b42614149ebccf12c9c580601ed01bd83070 upstream.

When `echo Y > /sys/module/usbcore/parameters/usbfs_snoop` and
usb_control_msg() returns error, a lot of kernel memory is dumped to dmesg
until unhandled kernel paging request occurs.

Signed-off-by: Michal Sojka 
Signed-off-by: Greg Kroah-Hartman

USB: Add support for SuperSpeed isoc endpoints

2011-03-23T19:50:21+00:00

commit 500132a0f26ad7d9916102193cbc6c1b1becb373 upstream.

Use the Mult and bMaxBurst values from the endpoint companion
descriptor to calculate the max length of an isoc transfer.

Add USB_SS_MULT macro to access Mult field of bmAttributes, at
Sarah's suggestion.

This patch should be queued for the 2.6.36 and 2.6.37 stable trees, since
those were the first kernels to have isochronous support for SuperSpeed
devices.

Signed-off-by: Paul Zimmerman 
Signed-off-by: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman

xhci: Fix cycle bit calculation during stall handling.

2011-03-23T19:50:20+00:00

commit 01a1fdb9a7afa5e3c14c9316d6f380732750b4e4 upstream.

When an endpoint stalls, we need to update the xHCI host's internal
dequeue pointer to move it past the stalled transfer.  This includes
updating the cycle bit (TRB ownership bit) if we have moved the dequeue
pointer past a link TRB with the toggle cycle bit set.

When we're trying to find the new dequeue segment, find_trb_seg() is
supposed to keep track of whether we've passed any link TRBs with the
toggle cycle bit set.  However, this while loop's body

	while (cur_seg->trbs > trb ||
			&cur_seg->trbs[TRBS_PER_SEGMENT - 1] < trb) {

Will never get executed if the ring only contains one segment.
find_trb_seg() will return immediately, without updating the new cycle
bit.  Since find_trb_seg() has no idea where in the segment the TD that
stalled was, make the caller, xhci_find_new_dequeue_state(), check for
this special case and update the cycle bit accordingly.

This patch should be queued to kernels all the way back to 2.6.31.

Signed-off-by: Sarah Sharp 
Tested-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

xhci: Update internal dequeue pointers after stalls.

2011-03-23T19:50:19+00:00

commit bf161e85fb153c0dd5a95faca73fd6a9d237c389 upstream.

When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer.  To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.

Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes.  However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.

Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command.  Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.

While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed.  This just won't work with
the internal xHCI state code.  I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB.  There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works.  Keep the fix simple until when/if we run into
that case.

This patch should be queued to kernels all the way back to 2.6.31.

Signed-off-by: Sarah Sharp 
Tested-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman