swh:1:snp:38ae39f9fd01a4b0ef06fab5668b65bf4c2aca03
Revision 831abf76643555a99b80a3b54adfa7e4fa0a3259 authored by Kurt Garloff on 24 September 2013, 12:13:48 UTC, committed by Greg Kroah-Hartman on 26 September 2013, 00:30:39 UTC
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 <kurt@garloff.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1 parent 2c74033
History
Tip revision: 0cdd776ec92c0fec768c7079331804d3e52d4b27 authored by Linus Torvalds on 15 May 2022, 15:08:51 UTC
Merge tag 'driver-core-5.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Tip revision: 0cdd776
File Mode Size
Documentation
arch
block
crypto
drivers
firmware
fs
include
init
ipc
kernel
lib
mm
net
samples
scripts
security
sound
tools
usr
virt
.gitignore -rw-r--r-- 1.1 KB
.mailmap -rw-r--r-- 4.4 KB
COPYING -rw-r--r-- 18.3 KB
CREDITS -rw-r--r-- 93.1 KB
Kbuild -rw-r--r-- 2.5 KB
Kconfig -rw-r--r-- 252 bytes
MAINTAINERS -rw-r--r-- 256.8 KB
Makefile -rw-r--r-- 47.4 KB
README -rw-r--r-- 18.3 KB
REPORTING-BUGS -rw-r--r-- 7.3 KB

README

back to top