linux-stable.git/drivers/hid/hid-input.c, branch linux-3.16.y

HID: hid-input: clear unmapped usages

2020-04-28T18:02:58+00:00

commit 4f3882177240a1f55e45a3d241d3121341bead78 upstream.

We should not be leaving half-mapped usages with potentially invalid
keycodes, as that may confuse hidinput_find_key() when the key is located
by index, which may end up feeding way too large keycode into the VT
keyboard handler and cause OOB write there:

BUG: KASAN: global-out-of-bounds in clear_bit include/asm-generic/bitops-instrumented.h:56 [inline]
BUG: KASAN: global-out-of-bounds in kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
BUG: KASAN: global-out-of-bounds in kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
Write of size 8 at addr ffffffff89a1b2d8 by task syz-executor108/1722
...
 kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
 kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
 input_to_handler+0x3b6/0x4c0 drivers/input/input.c:118
 input_pass_values.part.0+0x2e3/0x720 drivers/input/input.c:145
 input_pass_values drivers/input/input.c:949 [inline]
 input_set_keycode+0x290/0x320 drivers/input/input.c:954
 evdev_handle_set_keycode_v2+0xc4/0x120 drivers/input/evdev.c:882
 evdev_do_ioctl drivers/input/evdev.c:1150 [inline]

Reported-by: syzbot+19340dff067c2d3835c0@syzkaller.appspotmail.com
Signed-off-by: Dmitry Torokhov 
Tested-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Ben Hutchings

HID: clamp input to logical range if no null state

2018-11-20T18:05:59+00:00

commit c3883fe06488a483658ba5d849b70e49bee15e7c upstream.

This patch fixes an issue in drivers/hid/hid-input.c where values
outside of the logical range are not clamped when "null state" bit of
the input control is not set.

This was discussed on the lists [1] and this change stems from the fact
due to the ambiguity of the HID specification it might be appropriate to
follow Microsoft's own interpretation of the specification. As noted in
Microsoft's documentation [2] in the section titled "Required HID usages
for digitizers" it is noted that values reported outside the logical
range "will be considered as invalid data and the value will be changed
to the nearest boundary value (logical min/max)."

This patch fixes an issue where the (1292:4745) Innomedia INNEX
GENESIS/ATARI reports out of range values for its X and Y axis of the
DPad which, due to the null state bit being unset, are forwarded to
userspace as is. Now these values will get clamped to the logical range
before being forwarded to userspace. This device was also used to test
this patch.

This patch expands on commit 3f3752705dbd ("HID: reject input outside
logical range only if null state is set").

[1]: http://lkml.kernel.org/r/20170307131036.GA853@gaia.local
[2]: https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85).asp

Signed-off-by: Tomasz Kramkowski 
Acked-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Ben Hutchings

HID: reject input outside logical range only if null state is set

2018-11-20T18:05:59+00:00

commit 3f3752705dbd50b66b66ad7b4d54fe33d2f746ed upstream.

This patch fixes an issue in drivers/hid/hid-input.c where USB HID
control null state flag is not checked upon rejecting inputs outside
logical minimum-maximum range. The check should be made according to USB
HID specification 1.11, section 6.2.2.5, p.31. The fix will resolve
issues with some game controllers, such as:
https://bugzilla.kernel.org/show_bug.cgi?id=68621

[tk@the-tk.com: shortened and fixed spelling in commit message]
Signed-off-by: Valtteri Heikkilä 
Signed-off-by: Tomasz Kramkowski 
Acked-By: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Ben Hutchings

HID: hid-input: Add parentheses to quell gcc warning

2017-04-04T21:21:56+00:00

commit 09a5c34e8d6b05663ec4c3d22b1fbd9fec89aaf9 upstream.

GCC reports a -Wlogical-not-parentheses warning here; therefore
add parentheses to shut it up and to express our intent more.

Signed-off-by: James C Boyd 
Signed-off-by: Jiri Kosina 
Signed-off-by: Ben Hutchings 
Cc: Arnd Bergmann

HID: apple: fix battery support for the 2009 ANSI wireless keyboard

2015-03-23T15:17:50+00:00

commit cbd366bea2b8513bc0fc1c9e8832cb0ab221d6d5 upstream.

Enabled quirks necessary for correct battery capacity reporting. Cleaned up
surrounding style.

Signed-off-by: Ross Skaliotis 
Signed-off-by: Jiri Kosina 
Signed-off-by: Luis Henriques

HID: fixup the conflicting keyboard mappings quirk

2015-02-24T10:01:02+00:00

commit 8e7b341037db1835ee6eea64663013cbfcf33575 upstream.

The ignore check that got added in 6ce901eb61 ("HID: input: fix confusion
on conflicting mappings") needs to properly check for VARIABLE reports
as well (ARRAY reports should be ignored), otherwise legitimate keyboards
might break.

Fixes: 6ce901eb61 ("HID: input: fix confusion on conflicting mappings")
Reported-by: Fredrik Hallenberg 
Reported-by: David Herrmann 
Signed-off-by: Jiri Kosina 
Signed-off-by: Luis Henriques

HID: input: fix confusion on conflicting mappings

2015-02-24T10:01:01+00:00

commit 6ce901eb61aa30ba8565c62049ee80c90728ef14 upstream.

On an PC-101/103/104 keyboard (American layout) the 'Enter' key and its
neighbours look like this:

           +---+ +---+ +-------+
           | 1 | | 2 | |   5   |
           +---+ +---+ +-------+
             +---+ +-----------+
             | 3 | |     4     |
             +---+ +-----------+

On a PC-102/105 keyboard (European layout) it looks like this:

           +---+ +---+ +-------+
           | 1 | | 2 | |       |
           +---+ +---+ +-+  4  |
             +---+ +---+ |     |
             | 3 | | 5 | |     |
             +---+ +---+ +-----+

(Note that the number of keys is the same, but key '5' is moved down and
 the shape of key '4' is changed. Keys '1' to '3' are exactly the same.)

The keys 1-4 report the same scan-code in HID in both layouts, even though
the keysym they produce is usually different depending on the XKB-keymap
used by user-space.
However, key '5' (US 'backslash'/'pipe') reports 0x31 for the upper layout
and 0x32 for the lower layout, as defined by the HID spec. This is highly
confusing as the linux-input API uses a single keycode for both.

So far, this was never a problem as there never has been a keyboard with
both of those keys present at the same time. It would have to look
something like this:

           +---+ +---+ +-------+
           | 1 | | 2 | |  x31  |
           +---+ +---+ +-------+
             +---+ +---+ +-----+
             | 3 | |x32| |  4  |
             +---+ +---+ +-----+

HID can represent such a keyboard, but the linux-input API cannot.
Furthermore, any user-space mapping would be confused by this and,
luckily, no-one ever produced such hardware.

Now, the HID input layer fixed this mess by mapping both 0x31 and 0x32 to
the same keycode (KEY_BACKSLASH==0x2b). As only one of both physical keys
is present on a hardware, this works just fine.

Lets introduce hardware-vendors into this:
------------------------------------------

Unfortunately, it seems way to expensive to produce a different device for
American and European layouts. Therefore, hardware-vendors put both keys,
(0x31 and 0x32) on the same keyboard, but only one of them is hooked up
to the physical button, the other one is 'dead'.
This means, they can use the same hardware, with a different button-layout
and automatically produce the correct HID events for American *and*
European layouts. This is unproblematic for normal keyboards, as the
'dead' key will never report any KEY-DOWN events. But RollOver keyboards
send the whole matrix on each key-event, allowing n-key roll-over mode.
This means, we get a 0x31 and 0x32 event on each key-press. One of them
will always be 0, the other reports the real state. As we map both to the
same keycode, we will get spurious key-events, even though the real
key-state never changed.

The easiest way would be to blacklist 'dead' keys and never handle those.
We could simply read the 'country' tag of USB devices and blacklist either
key according to the layout. But... hardware vendors... want the same
device for all countries and thus many of them set 'country' to 0 for all
devices. Meh..

So we have to deal with this properly. As we cannot know which of the keys
is 'dead', we either need a heuristic and track those keys, or we simply
make use of our value-tracking for HID fields. We simply ignore HID events
for absolute data if the data didn't change. As HID tracks events on the
HID level, we haven't done the keycode translation, yet. Therefore, the
'dead' key is tracked independently of the real key, therefore, any events
on it will be ignored.

This patch simply discards any HID events for absolute data if it didn't
change compared to the last report. We need to ignore relative and
buffered-byte reports for obvious reasons. But those cannot be affected by
this bug, so we're fine.

Preferably, we'd do this filtering on the HID-core level. But this might
break a lot of custom drivers, if they do not follow the HID specs.
Therefore, we do this late in hid-input just before we inject it into the
input layer (which does the exact same filtering, but on the keycode
level).

If this turns out to break some devices, we might have to limit filtering
to EV_KEY events. But lets try to do the Right Thing first, and properly
filter any absolute data that didn't change.

This patch is tagged for 'stable' as it fixes a lot of n-key RollOver
hardware. We might wanna wait with backporting for a while, before we know
it doesn't break anything else, though.

Reported-by: Adam Goode 
Reported-by: Fredrik Hallenberg 
Tested-by: Fredrik Hallenberg 
Signed-off-by: David Herrmann 
Signed-off-by: Jiri Kosina 
Signed-off-by: Luis Henriques

HID: add battery quirk for USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ISO keyboard

2015-01-16T14:34:43+00:00

commit da940db41dcf8c04166f711646df2f35376010aa upstream.

Apple bluetooth wireless keyboard (sold in UK) has always reported zero
for battery strength no matter what condition the batteries are actually
in. With this patch applied (applying same quirk as other Apple
keyboards), the battery strength is now correctly reported.

Signed-off-by: Karl Relton 
Signed-off-by: Jiri Kosina 
Signed-off-by: Luis Henriques

HID: add keyboard input assist hid usages

2014-11-17T14:11:57+00:00

commit f974008f07a62171a9dede08250c9a35c2b2b986 upstream.

Add keyboard input assist controls usages from approved
hid usage table request HUTTR42:
http://www.usb.org/developers/hidpage/HUTRR42c.pdf

Signed-off-by: Olivier Gay 
Acked-by: Dmitry Torokhov 
Signed-off-by: Jiri Kosina 
Signed-off-by: Luis Henriques

HID: input: Fix TransducerSerialNumber implementation

2014-11-17T14:11:54+00:00

commit 5989a55a4c9aafba8b152c6bf52244510c2b88b9 upstream.

The commit which introduced TransducerSerialNumber (368c966) is missing
two crucial implementation details. Firstly, the commit does not set the
type/code/bit/max fields as expected later down the code which can cause
the driver to crash when a tablet with this usage is connected. Secondly,
the call to 'set_bit' causes MSC_PULSELED to be sent instead of the
expected MSC_SERIAL. This commit addreses both issues.

Signed-off-by: Jason Gerecke 
Reviewed-by: Benjamin Tissoires 
Reviewed-by: Ping Cheng 
Signed-off-by: Jiri Kosina 
Signed-off-by: Luis Henriques