kernel/linux.git/drivers/usb/class, branch v3.0.35

USB: cdc-wdm: poll must return POLLHUP if device is gone

2012-06-01T07:12:55+00:00

commit 616b6937e348ef2b4c6ea5fef2cd3c441145efb0 upstream. Else the poll will be restarted indefinitely in a tight loop, preventing final device cleanup. Cc: Oliver Neukum Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman

USB: cdc-wdm: fix race leading leading to memory corruption

2012-05-07T15:56:36+00:00

commit 5c22837adca7c30b66121cf18ad3e160134268d4 upstream. This patch fixes a race whereby a pointer to a buffer would be overwritten while the buffer was in use leading to a double free and a memory leak. This causes crashes. This bug was introduced in 2.6.34 Signed-off-by: Oliver Neukum Tested-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman

cdc-wdm: Don't clear WDM_READ unless entire read buffer is emptied

2012-04-02T16:27:04+00:00

commit b7a205545345578712611106b371538992e142ff upstream. The WDM_READ flag is cleared later iff desc->length is reduced to 0. Signed-off-by: Ben Hutchings Tested-by: Bjørn Mork Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman

cdc-wdm: Fix more races on the read path

2012-04-02T16:26:59+00:00

commit 711c68b3c0f7a924ffbee4aa962d8f62b85188ff upstream. We must not allow the input buffer length to change while we're shuffling the buffer contents. We also mustn't clear the WDM_READ flag after more data might have arrived. Therefore move both of these into the spinlocked region at the bottom of wdm_read(). When reading desc->length without holding the iuspin lock, use ACCESS_ONCE() to ensure the compiler doesn't re-read it with inconsistent results. Signed-off-by: Ben Hutchings Tested-by: Bjørn Mork Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman

USB: cdc-wdm: Avoid hanging on interface with no USB_CDC_DMM_TYPE

2012-02-03T17:19:02+00:00

commit 15699e6fafc3a90e5fdc2ef30555a04dee62286f upstream. The probe does not strictly require the USB_CDC_DMM_TYPE descriptor, which is a good thing as it makes the driver usable on non-conforming interfaces. A user could e.g. bind to it to a CDC ECM interface by using the new_id and bind sysfs files. But this would fail with a 0 buffer length due to the missing descriptor. Fix by defining a reasonable fallback size: The minimum device receive buffer size required by the CDC WMC standard, revision 1.1 Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman

USB: cdc-wdm: better allocate a buffer that is at least as big as we tell the USB core

2012-02-03T17:19:02+00:00

commit 655e247daf52b202a6c2d0f8a06dd2051e756ce4 upstream. As it turns out, there was a mismatch between the allocated inbuf size (desc->bMaxPacketSize0, typically something like 64) and the length we specified in the URB (desc->wMaxCommand, typically something like 2048) Signed-off-by: Bjørn Mork Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman

USB: cdc-wdm: call wake_up_all to allow driver to shutdown on device removal

2012-02-03T17:19:02+00:00

commit 62aaf24dc125d7c55c93e313d15611f152b030c7 upstream. wdm_disconnect() waits for the mutex held by wdm_read() before calling wake_up_all(). This causes a deadlock, preventing device removal to complete. Do the wake_up_all() before we start waiting for the locks. Signed-off-by: Bjørn Mork Cc: Oliver Neukum Cc: stable Signed-off-by: Greg Kroah-Hartman

USB: cdc-wdm: use two mutexes to allow simultaneous read and write

2012-02-03T17:18:59+00:00

commit e8537bd2c4f325a4796da33564ddcef9489b7feb upstream. using a separate read and write mutex for locking is sufficient to make the driver accept simultaneous read and write. This improves useability a lot. Signed-off-by: Bjørn Mork Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman

USB: cdc-wdm: updating desc->length must be protected by spin_lock

2012-02-03T17:18:59+00:00

commit c428b70c1e115c5649707a602742e34130d19428 upstream. wdm_in_callback() will also touch this field, so we cannot change it without locking Signed-off-by: Bjørn Mork Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman

usb: cdc-acm: Fix acm_tty_hangup() vs. acm_tty_close() race

2012-01-12T19:35:53+00:00

[Not upstream as it was fixed differently for 3.3 with a much more "intrusive" rework of the driver - gregkh] There is a race condition involving acm_tty_hangup() and acm_tty_close() where hangup() would attempt to access tty->driver_data without proper locking and NULL checking after close() has potentially already set it to NULL. One possibility to (sporadically) trigger this behavior is to perform a suspend/resume cycle with a running WWAN data connection. This patch addresses the issue by introducing a NULL check for tty->driver_data in acm_tty_hangup() protected by open_mutex and exiting gracefully when hangup() is invoked on a device that has already been closed. Signed-off-by: Thilo-Alexander Ginkel Signed-off-by: Greg Kroah-Hartman