linux-stable.git/drivers/usb/core/devio.c, branch v3.12.44

USB: usbfs: don't leak kernel data in siginfo

2015-03-12T16:31:13+00:00

commit f0c2b68198589249afd2b1f2c4e8de8c03e19c16 upstream.

When a signal is delivered, the information in the siginfo structure
is copied to userspace.  Good security practice dicatates that the
unused fields in this structure should be initialized to 0 so that
random kernel stack data isn't exposed to the user.  This patch adds
such an initialization to the two places where usbfs raises signals.

Signed-off-by: Alan Stern 
Reported-by: Dave Mielke 
Signed-off-by: Jiri Slaby

USB: devio: fix issue with log flooding

2014-09-03T19:31:13+00:00

commit d310d05f1225d1f6f2bf505255fdf593bfbb3051 upstream.

usbfs allows user space to pass down an URB which sets URB_SHORT_NOT_OK
for output URBs. That causes usbcore to log messages without limit
for a nonsensical disallowed combination. The fix is to silently drop
the attribute in usbfs.
The problem is reported to exist since 3.14
https://www.virtualbox.org/ticket/13085

Signed-off-by: Oliver Neukum 
Acked-by: Alan Stern 
Signed-off-by: Jiri Slaby

usb/core/devio.c: Don't reject control message to endpoint with wrong direction bit

2013-09-26T00:30:39+00:00

Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101)
[1] with the Windows App (EasyNote) works natively but fails when
Windows is running under KVM (and the USB device handed to KVM).

The reason is a USB control message
 usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008
This goes to endpoint address 0x01 (wIndex); however, endpoint address
0x01 does not exist. There is an endpoint 0x81 though (same number,
but other direction); the app may have meant that endpoint instead.

The kernel thus rejects the IO and thus we see the failure.

Apparently, Linux is more strict here than Windows ... we can't change
the Win app easily, so that's a problem.

It seems that the Win app/driver is buggy here and the driver does not
behave fully according to the USB HID class spec that it claims to
belong to.  The device seems to happily deal with that though (and
seems to not really care about this value much).

So the question is whether the Linux kernel should filter here.
Rejecting has the risk that somewhat non-compliant userspace apps/
drivers (most likely in a virtual machine) are prevented from working.
Not rejecting has the risk of confusing an overly sensitive device with
such a transfer. Given the fact that Windows does not filter it makes
this risk rather small though.

The patch makes the kernel more tolerant: If the endpoint address in
wIndex does not exist, but an endpoint with toggled direction bit does,
it will let the transfer through. (It does NOT change the message.)

With attached patch, the app in Windows in KVM works.
 usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but needs 81

I suspect this will mostly affect apps in virtual environments; as on
Linux the apps would have been adapted to the stricter handling of the
kernel. I have done that for mine[2].

[1] http://www.pegatech.com/
[2] https://sourceforge.net/projects/notetakerpen/

Signed-off-by: Kurt Garloff 
Acked-by: Alan Stern 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

usbfs: Allow printer class 'get_device_id' without needing to claim the intf

2013-07-25T19:01:12+00:00

For certain (HP) printers the printer device_id does not only contain a
static part identifying the printer, but it also contains a dynamic part
giving printer status, ink level, etc.

To get to this info various userspace utilities need to be able to make a
printer class 'get_device_id' request without first claiming the interface
(as that is in use for the actual printer driver).

Since the printer class 'get_device_id' request does not change interface
settings in anyway, allowing this without claiming the interface should not
cause any issues.

CC: Sanjay Kumar 
CC: Alan Stern 
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

Merge 3.10-rc5 into usb-next

2013-06-09T04:27:51+00:00

We need the changes in this branch.

Signed-off-by: Greg Kroah-Hartman

usbfs: Increase arbitrary limit for USB 3 isopkt length

2013-05-29T08:06:36+00:00

Increase the current arbitrary limit for isocronous packet size to a
value large enough to account for USB 3.0 super bandwidth streams,
bMaxBurst (0~15 allowed, 1~16 packets)
bmAttributes (bit 1:0, mult 0~2, 1~3 packets)
so the size max for one USB 3 isocronous transfer is
1024 byte * 16 * 3 = 49152 byte

Acked-by: Alan Stern 
Signed-off-by: Federico Manzan 
Signed-off-by: Greg Kroah-Hartman

usb: devio: Fixed error: 'do not use assignment in if condition'

2013-05-17T17:05:57+00:00

This patch fixes error: 'do not use assignment in if condition'
in USB/devio.c.

Signed-off-by: Tülin İzer 
Signed-off-by: Greg Kroah-Hartman

usb: devio: Fixed macro parenthesis error

2013-05-17T17:05:57+00:00

This patch fixes error 'Macros with complex values should be enclosed in
parenthesis' in USB/devio.c

Signed-off-by: Tülin İzer 
Signed-off-by: Greg Kroah-Hartman

usb: devio: Fixed warning: 'use instead '

2013-05-17T17:05:56+00:00

This patch fixes warning: 'use  instead '
found by checkpatch in usb/devio.c.

Signed-off-by: Tülin İzer 
Signed-off-by: Greg Kroah-Hartman

usbfs: Always allow ctrl requests with USB_RECIP_ENDPOINT on the ctrl ep

2013-04-17T17:01:22+00:00

When usbfs receives a ctrl-request from userspace it calls check_ctrlrecip,
which for a request with USB_RECIP_ENDPOINT tries to map this to an interface
to see if this interface is claimed, except for ctrl-requests with a type of
USB_TYPE_VENDOR.

When trying to use this device: http://www.akaipro.com/eiepro
redirected to a Windows vm running on qemu on top of Linux.

The windows driver makes a ctrl-req with USB_TYPE_CLASS and
USB_RECIP_ENDPOINT with index 0, and the mapping of the endpoint (0) to
the interface fails since ep 0 is the ctrl endpoint and thus never is
part of an interface.

This patch fixes this ctrl-req failing by skipping the checkintf call for
USB_RECIP_ENDPOINT ctrl-reqs on the ctrl endpoint.

Reported-by: Dave Stikkolorum 
Tested-by: Dave Stikkolorum 
Signed-off-by: Hans de Goede 
Acked-by: Alan Stern 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman