linux-stable.git/drivers/usb, branch linux-2.6.32.y Linux kernel stable tree USB: visor: fix null-deref at probe 2016-03-12T13:25:39+00:00 Johan Hovold johan@kernel.org 2016-01-12T11:05:20+00:00 ea26131ff39cf3517a784672368ad17fbdeba5eb commit cac9b50b0d75a1d50d6c056ff65c005f3224c8e0 upstream. Fix null-pointer dereference at probe should a (malicious) Treo device lack the expected endpoints. Specifically, the Treo port-setup hack was dereferencing the bulk-in and interrupt-in urbs without first making sure they had been allocated by core. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Willy Tarreau <w@1wt.eu> 
commit cac9b50b0d75a1d50d6c056ff65c005f3224c8e0 upstream.

Fix null-pointer dereference at probe should a (malicious) Treo device
lack the expected endpoints.

Specifically, the Treo port-setup hack was dereferencing the bulk-in and
interrupt-in urbs without first making sure they had been allocated by
core.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
usb: serial: visor: fix crash on detecting device without write_urbs 2016-03-12T13:25:39+00:00 Vladis Dronov vdronov@redhat.com 2016-01-12T14:10:50+00:00 f188d26db58a19d21a4c168d330e4b00b0df9306 commit cb3232138e37129e88240a98a1d2aba2187ff57c upstream. The visor driver crashes in clie_5_attach() when a specially crafted USB device without bulk-out endpoint is detected. This fix adds a check that the device has proper configuration expected by the driver. Reported-by: Ralf Spenneberg <ralf@spenneberg.net> Signed-off-by: Vladis Dronov <vdronov@redhat.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Willy Tarreau <w@1wt.eu> 
commit cb3232138e37129e88240a98a1d2aba2187ff57c upstream.

The visor driver crashes in clie_5_attach() when a specially crafted USB
device without bulk-out endpoint is detected. This fix adds a check that
the device has proper configuration expected by the driver.

Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
USB: fix invalid memory access in hub_activate() 2016-01-29T21:12:55+00:00 Alan Stern stern@rowland.harvard.edu 2015-12-16T18:32:38+00:00 533030ca4271aea2f1fc95a3c64840654feebafe commit e50293ef9775c5f1cf3fcc093037dd6a8c5684ea upstream. Commit 8520f38099cc ("USB: change hub initialization sleeps to delayed_work") changed the hub_activate() routine to make part of it run in a workqueue. However, the commit failed to take a reference to the usb_hub structure or to lock the hub interface while doing so. As a result, if a hub is plugged in and quickly unplugged before the work routine can run, the routine will try to access memory that has been deallocated. Or, if the hub is unplugged while the routine is running, the memory may be deallocated while it is in active use. This patch fixes the problem by taking a reference to the usb_hub at the start of hub_activate() and releasing it at the end (when the work is finished), and by locking the hub interface while the work routine is running. It also adds a check at the start of the routine to see if the hub has already been disconnected, in which nothing should be done. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Alexandru Cornea <alexandru.cornea@intel.com> Tested-by: Alexandru Cornea <alexandru.cornea@intel.com> Fixes: 8520f38099cc ("USB: change hub initialization sleeps to delayed_work") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: add prototype for hub_release() before first use] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> (cherry picked from commit 10037421b529bc1fc18994e94e37d745184c4ea9) [wt: made a few changes : - adjusted context due to some autopm code being added only in 2.6.33 - no device_{lock,unlock}() in 2.6.32, use up/down(&->sem) instead] Signed-off-by: Willy Tarreau <w@1wt.eu> 
commit e50293ef9775c5f1cf3fcc093037dd6a8c5684ea upstream.

Commit 8520f38099cc ("USB: change hub initialization sleeps to
delayed_work") changed the hub_activate() routine to make part of it
run in a workqueue.  However, the commit failed to take a reference to
the usb_hub structure or to lock the hub interface while doing so.  As
a result, if a hub is plugged in and quickly unplugged before the work
routine can run, the routine will try to access memory that has been
deallocated.  Or, if the hub is unplugged while the routine is
running, the memory may be deallocated while it is in active use.

This patch fixes the problem by taking a reference to the usb_hub at
the start of hub_activate() and releasing it at the end (when the work
is finished), and by locking the hub interface while the work routine
is running.  It also adds a check at the start of the routine to see
if the hub has already been disconnected, in which nothing should be
done.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Alexandru Cornea <alexandru.cornea@intel.com>
Tested-by: Alexandru Cornea <alexandru.cornea@intel.com>
Fixes: 8520f38099cc ("USB: change hub initialization sleeps to delayed_work")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: add prototype for hub_release() before first use]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 10037421b529bc1fc18994e94e37d745184c4ea9)
[wt: made a few changes :
  - adjusted context due to some autopm code being added only in 2.6.33
  - no device_{lock,unlock}() in 2.6.32, use up/down(&->sem) instead]
Signed-off-by: Willy Tarreau <w@1wt.eu>
USB: ipaq.c: fix a timeout loop 2016-01-29T21:12:55+00:00 Dan Carpenter dan.carpenter@oracle.com 2015-12-16T11:06:37+00:00 00972bcd1fec22d93d6aa68e010b93d53a48b0fe commit abdc9a3b4bac97add99e1d77dc6d28623afe682b upstream. The code expects the loop to end with "retries" set to zero but, because it is a post-op, it will end set to -1. I have fixed this by moving the decrement inside the loop. Fixes: 014aa2a3c32e ('USB: ipaq: minor ipaq_open() cleanup.') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> (cherry picked from commit 53a68d3f1629de82ddeb4e0882b0727fc230a6f3) Signed-off-by: Willy Tarreau <w@1wt.eu> 
commit abdc9a3b4bac97add99e1d77dc6d28623afe682b upstream.

The code expects the loop to end with "retries" set to zero but, because
it is a post-op, it will end set to -1.  I have fixed this by moving the
decrement inside the loop.

Fixes: 014aa2a3c32e ('USB: ipaq: minor ipaq_open() cleanup.')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 53a68d3f1629de82ddeb4e0882b0727fc230a6f3)
Signed-off-by: Willy Tarreau <w@1wt.eu>
xhci: fix off by one error in TRB DMA address boundary check 2015-12-05T23:49:04+00:00 Mathias Nyman mathias.nyman@linux.intel.com 2015-08-03T13:07:48+00:00 70397cf66e8d1ac9b06726f5825d03342996763d commit 7895086afde2a05fa24a0e410d8e6b75ca7c8fdd upstream. We need to check that a TRB is part of the current segment before calculating its DMA address. Previously a ring segment didn't use a full memory page, and every new ring segment got a new memory page, so the off by one error in checking the upper bound was never seen. Now that we use a full memory page, 256 TRBs (4096 bytes), the off by one didn't catch the case when a TRB was the first element of the next segment. This is triggered if the virtual memory pages for a ring segment are next to each in increasing order where the ring buffer wraps around and causes errors like: [ 106.398223] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 1 [ 106.398230] xhci_hcd 0000:00:14.0: Looking for event-dma fffd3000 trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 seg-end fffd4ff0 The trb-end address is one outside the end-seg address. Tested-by: Arkadiusz Miśkiewicz <arekm@maven.pl> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> (cherry picked from commit 6e3ae6256145b5597bee0296eb5fc384cd86aa3d) Signed-off-by: Willy Tarreau <w@1wt.eu> 
commit 7895086afde2a05fa24a0e410d8e6b75ca7c8fdd upstream.

We need to check that a TRB is part of the current segment
before calculating its DMA address.

Previously a ring segment didn't use a full memory page, and every
new ring segment got a new memory page, so the off by one
error in checking the upper bound was never seen.

Now that we use a full memory page, 256 TRBs (4096 bytes), the off by one
didn't catch the case when a TRB was the first element of the next segment.

This is triggered if the virtual memory pages for a ring segment are
next to each in increasing order where the ring buffer wraps around and
causes errors like:

[  106.398223] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 1
[  106.398230] xhci_hcd 0000:00:14.0: Looking for event-dma fffd3000 trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 seg-end fffd4ff0

The trb-end address is one outside the end-seg address.

Tested-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 6e3ae6256145b5597bee0296eb5fc384cd86aa3d)
Signed-off-by: Willy Tarreau <w@1wt.eu>
USB: whiteheat: fix potential null-deref at probe 2015-12-05T23:49:03+00:00 Johan Hovold johan@kernel.org 2015-09-23T18:41:42+00:00 86a283d33519999a70478f20127ed1fa8af9e3bc commit cbb4be652d374f64661137756b8f357a1827d6a4 upstream. Fix potential null-pointer dereference at probe by making sure that the required endpoints are present. The whiteheat driver assumes there are at least five pairs of bulk endpoints, of which the final pair is used for the "command port". An attempt to bind to an interface with fewer bulk endpoints would currently lead to an oops. Fixes CVE-2015-5257. Reported-by: Moein Ghasemzadeh <moein@istuary.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Willy Tarreau <w@1wt.eu> 
commit cbb4be652d374f64661137756b8f357a1827d6a4 upstream.

Fix potential null-pointer dereference at probe by making sure that the
required endpoints are present.

The whiteheat driver assumes there are at least five pairs of bulk
endpoints, of which the final pair is used for the "command port". An
attempt to bind to an interface with fewer bulk endpoints would
currently lead to an oops.

Fixes CVE-2015-5257.

Reported-by: Moein Ghasemzadeh <moein@istuary.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
USB: whiteheat: Added bounds checking for bulk command response 2014-12-13T14:16:14+00:00 James Forshaw forshaw@google.com 2014-09-17T09:21:53+00:00 476b176f150a039d7f65784637295ae016e74d6d commit c5fd4126151855330280ea9382684980afcfdd03 upstream This patch fixes a potential security issue in the whiteheat USB driver which might allow a local attacker to cause kernel memory corrpution. This is due to an unchecked memcpy into a fixed size buffer (of 64 bytes). On EHCI and XHCI busses it's possible to craft responses greater than 64 bytes leading a buffer overflow. Signed-off-by: James Forshaw <forshaw@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (backported from commit 6817ae225cd650fb1c3295d769298c38b1eba818) CVE-2014-3185 BugLink: http://bugs.launchpad.net/bugs/1370036 Signed-off-by: Luis Henriques <luis.henriques@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Willy Tarreau <w@1wt.eu> 
commit c5fd4126151855330280ea9382684980afcfdd03 upstream

This patch fixes a potential security issue in the whiteheat USB driver
which might allow a local attacker to cause kernel memory corrpution. This
is due to an unchecked memcpy into a fixed size buffer (of 64 bytes). On
EHCI and XHCI busses it's possible to craft responses greater than 64
bytes leading a buffer overflow.

Signed-off-by: James Forshaw <forshaw@google.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(backported from commit 6817ae225cd650fb1c3295d769298c38b1eba818)
CVE-2014-3185
BugLink: http://bugs.launchpad.net/bugs/1370036
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
USB: add new zte 3g-dongle's pid to option.c 2014-11-23T09:55:53+00:00 Rui li li.rui27@zte.com.cn 2012-01-31T07:27:33+00:00 673c64e0912b531f87db84d9c3d3f25737e91b5a As ZTE have and will use more pid for new products this year, so we need to add some new zte 3g-dongle's pid on option.c , and delete one pid 0x0154 because it use for mass-storage port. Signed-off-by: Rui li <li.rui27@zte.com.cn> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 1608ea5f4b5d6262cd6e808839491cfb2a67405a) Signed-off-by: Willy Tarreau <w@1wt.eu> 
As ZTE have and will use more pid for new products this year,
so we need to add some new zte 3g-dongle's pid on option.c ,
and delete one pid 0x0154 because it use for mass-storage port.

Signed-off-by: Rui li <li.rui27@zte.com.cn>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 1608ea5f4b5d6262cd6e808839491cfb2a67405a)
Signed-off-by: Willy Tarreau <w@1wt.eu>
USB: kobil_sct: fix non-atomic allocation in write path 2014-11-23T09:55:46+00:00 Johan Hovold johan@kernel.org 2014-10-29T08:07:30+00:00 faa4cc13e7acb2d1f313290b556d5b7401cc65c8 Write may be called from interrupt context so make sure to use GFP_ATOMIC for all allocations in write. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> (cherry picked from commit 191252837626fca0de694c18bb2aa64c118eda89) Signed-off-by: Willy Tarreau <w@1wt.eu> 
Write may be called from interrupt context so make sure to use
GFP_ATOMIC for all allocations in write.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
(cherry picked from commit 191252837626fca0de694c18bb2aa64c118eda89)
Signed-off-by: Willy Tarreau <w@1wt.eu>
USB: ftdi_sio: Quiet sparse noise about using plain integer was NULL pointer 2013-06-10T09:43:06+00:00 Ying Xue ying.xue@windriver.com 2012-08-06T09:46:37+00:00 b7924161e554fa880c9c9c1c987f6800abc7ce29 commit a816e3113b63753c330ca4751ea1d208e93e3015 upstream. Pointers should not be compared to plain integers. Quiets the sparse warning: warning: Using plain integer as NULL pointer Signed-off-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Lotfi Manseur <lotfi.manseur@imag.fr> Signed-off-by: Willy Tarreau <w@1wt.eu> 
commit a816e3113b63753c330ca4751ea1d208e93e3015 upstream.

Pointers should not be compared to plain integers.
Quiets the sparse warning:
warning: Using plain integer as NULL pointer

Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested-by: Lotfi Manseur <lotfi.manseur@imag.fr>
Signed-off-by: Willy Tarreau <w@1wt.eu>