linux.git/drivers/usb/core, branch v3.12-rc4

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

usbcore: check usb device's state before sending a Set SEL control transfer

2013-09-23T22:43:32+00:00

Set SEL control urbs cannot be sent to a device in unconfigured state.
This patch adds a check in usb_req_set_sel() to ensure the usb device's
state is USB_STATE_CONFIGURED.

Signed-off-by: Xenia Ragiadakou 
Reported-by: Martin MOKREJS 
Suggested-by: Sarah Sharp 
Signed-off-by: Sarah Sharp

usbcore: fix incorrect type in assignment in descriptors_changed()

2013-08-31T01:50:43+00:00

This patch fixes the incorrect assignment of a variable with type 'le16'
to a variable with type 'unsigned int'.

Signed-off-by: Xenia Ragiadakou 
Reported-by: kbuild test robot 
Signed-off-by: Greg Kroah-Hartman

usbcore: compare and release one bos descriptor in usb_reset_and_verify_device()

2013-08-30T19:02:08+00:00

In usb_reset_and_verify_device(), hub_port_init() allocates a new bos
descriptor to hold the value read by the device. The new bos descriptor
has to be compared with the old one in order to figure out if device 's
firmware has changed in which case the device has to be reenumerated.
In the original code, none of the two descriptors was deallocated leading
to memory leaks.

This patch compares the old bos descriptor with the new one to detect change
in firmware and releases the newly allocated bos descriptor to prevent memory
leak.

Signed-off-by: Xenia Ragiadakou 
Reported-by: Martin MOKREJS 
Tested-by: Martin MOKREJS 
Suggested-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

USB: core: be specific about attribute permissions

2013-08-25T22:12:03+00:00

Instead of having to audit all sysfs attributes, to ensure we get them
right, use the default macros the driver core provides us (read-only,
read-write) to make the code simpler, and to prevent any mistakes from
ever happening.

Signed-off-by: Greg Kroah-Hartman

USB: core: use DRIVER_ATTR_RW()

2013-08-23T22:12:14+00:00

Use DRIVER_ATTR_RW() to make it easier to audit sysfs file permissions.

Signed-off-by: Greg Kroah-Hartman

usb: don't use bNbrPorts after initialization

2013-08-23T17:47:17+00:00

After successful initialization hub->descriptor->bNbrPorts and
hub->hdev->maxchild are equal, but using hub->hdev->maxchild is
preferred because that value is explicitly used for initialization
of hub->ports[].

Signed-off-by: Krzysztof Mazur 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: fail on usb_hub_create_port_device() errors

2013-08-23T17:47:17+00:00

Ignoring usb_hub_create_port_device() errors cause later NULL pointer
deference when uninitialized hub->ports[i] entries are dereferenced
after port memory allocation error.

Signed-off-by: Krzysztof Mazur 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: fix cleanup after failure in hub_configure()

2013-08-23T17:46:03+00:00

If the hub_configure() fails after setting the hdev->maxchild
the hub->ports might be NULL or point to uninitialized kzallocated
memory causing NULL pointer dereference in hub_quiesce() during cleanup.

Now after such error the hdev->maxchild is set to 0 to avoid cleanup
of uninitialized ports.

Signed-off-by: Krzysztof Mazur 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'for-usb-2013-08-15-step-1' into for-usb-next

2013-08-16T01:00:46+00:00

xhci: Step 1 to fix usb-linus and usb-next.

Hi Greg,

This is the first of three steps to fix your usb-linus and usb-next
trees.  As I mentioned, commit 4fae6f0fa86f92e6bc7429371b1e177ad0aaac66
"USB: handle LPM errors during device suspend correctly" was incorrectly
added to usb-next when it should have been added to usb-linus and marked
for stable.

Two port power off bug fixes touch the same code that patch touches, but
it's not easy to simply move commit 4fae6f0f patch to usb-linus because
commit 28e861658e23ca94692f98e245d254c75c8088a7 "USB: refactor code for
enabling/disabling remote wakeup" also touched those code sections.

I propose a two step process to fix this:

1. Pull these four patches into usb-linus.

2. Revert commit 28e861658e23ca94692f98e245d254c75c8088a7 from usb-next.
   Merge usb-linus into usb-next, and resolve the conflicts.

I will be sending pull requests for these steps.

This pull request is step one, and contains the backported version of
commit 4fae6f0fa86f92e6bc7429371b1e177ad0aaac66, the two port power off
fixes, and an unrelated xhci-plat bug fix.

Sarah Sharp

Resolved conflicts:
	drivers/usb/core/hub.c