linux-stable.git/drivers/hid, branch v5.8.7

HID: core: Sanitize event code and type when mapping input

2020-09-05T09:24:01+00:00

commit 35556bed836f8dc07ac55f69c8d17dce3e7f0e25 upstream.

When calling into hid_map_usage(), the passed event code is
blindly stored as is, even if it doesn't fit in the associated bitmap.

This event code can come from a variety of sources, including devices
masquerading as input devices, only a bit more "programmable".

Instead of taking the event code at face value, check that it actually
fits the corresponding bitmap, and if it doesn't:
- spit out a warning so that we know which device is acting up
- NULLify the bitmap pointer so that we catch unexpected uses

Code paths that can make use of untrusted inputs can now check
that the mapping was indeed correct and bail out if not.

Cc: stable@vger.kernel.org
Signed-off-by: Marc Zyngier 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Greg Kroah-Hartman

HID: core: Correctly handle ReportSize being zero

2020-09-05T09:24:01+00:00

commit bce1305c0ece3dc549663605e567655dd701752c upstream.

It appears that a ReportSize value of zero is legal, even if a bit
non-sensical. Most of the HID code seems to handle that gracefully,
except when computing the total size in bytes. When fed as input to
memset, this leads to some funky outcomes.

Detect the corner case and correctly compute the size.

Cc: stable@vger.kernel.org
Signed-off-by: Marc Zyngier 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Greg Kroah-Hartman

HID: hiddev: Fix slab-out-of-bounds write in hiddev_ioctl_usage()

2020-09-03T09:29:51+00:00

commit 25a097f5204675550afb879ee18238ca917cba7a upstream.

`uref->usage_index` is not always being properly checked, causing
hiddev_ioctl_usage() to go out of bounds under some cases. Fix it.

Reported-by: syzbot+34ee1b45d88571c2fa8b@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=f2aebe90b8c56806b050a20b36f51ed6acabe802
Reviewed-by: Dan Carpenter 
Signed-off-by: Peilin Ye 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: i2c-hid: Always sleep 60ms after I2C_HID_PWR_ON commands

2020-09-03T09:29:39+00:00

commit eef4016243e94c438f177ca8226876eb873b9c75 upstream.

Before this commit i2c_hid_parse() consists of the following steps:

1. Send power on cmd
2. usleep_range(1000, 5000)
3. Send reset cmd
4. Wait for reset to complete (device interrupt, or msleep(100))
5. Send power on cmd
6. Try to read HID descriptor

Notice how there is an usleep_range(1000, 5000) after the first power-on
command, but not after the second power-on command.

Testing has shown that at least on the BMAX Y13 laptop's i2c-hid touchpad,
not having a delay after the second power-on command causes the HID
descriptor to read as all zeros.

In case we hit this on other devices too, the descriptor being all zeros
can be recognized by the following message being logged many, many times:

hid-generic 0018:0911:5288.0002: unknown main item tag 0x0

At the same time as the BMAX Y13's touchpad issue was debugged,
Kai-Heng was working on debugging some issues with Goodix i2c-hid
touchpads. It turns out that these need a delay after a PWR_ON command
too, otherwise they stop working after a suspend/resume cycle.
According to Goodix a delay of minimal 60ms is needed.

Having multiple cases where we need a delay after sending the power-on
command, seems to indicate that we should always sleep after the power-on
command.

This commit fixes the mentioned issues by moving the existing 1ms sleep to
the i2c_hid_set_power() function and changing it to a 60ms sleep.

Cc: stable@vger.kernel.org
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208247
Reported-by: Kai-Heng Feng 
Reported-and-tested-by: Andrea Borgia 
Signed-off-by: Hans de Goede 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: quirks: add NOGET quirk for Logitech GROUP

2020-09-03T09:29:20+00:00

[ Upstream commit 68f775ddd2a6f513e225f9a565b054ab48fef142 ]

Add HID_QUIRK_NOGET for Logitech GROUP device.

Logitech GROUP is a compound with camera and audio.
When the HID interface in an audio device is requested to get
specific report id, all following control transfers are stalled
and never be restored back.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=203419
Signed-off-by: Ikjoon Jang 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: input: Fix devices that return multiple bytes in battery report

2020-08-19T06:26:03+00:00

commit 4f57cace81438cc873a96f9f13f08298815c9b51 upstream.

Some devices, particularly the 3DConnexion Spacemouse wireless 3D
controllers, return more than just the battery capacity in the battery
report. The Spacemouse devices return an additional byte with a device
specific field. However, hidinput_query_battery_capacity() only
requests a 2 byte transfer.

When a spacemouse is connected via USB (direct wire, no wireless dongle)
and it returns a 3 byte report instead of the assumed 2 byte battery
report the larger transfer confuses and frightens the USB subsystem
which chooses to ignore the transfer. Then after 2 seconds assume the
device has stopped responding and reset it. This can be reproduced
easily by using a wired connection with a wireless spacemouse. The
Spacemouse will enter a loop of resetting every 2 seconds which can be
observed in dmesg.

This patch solves the problem by increasing the transfer request to 4
bytes instead of 2. The fix isn't particularly elegant, but it is simple
and safe to backport to stable kernels. A further patch will follow to
more elegantly handle battery reports that contain additional data.

Signed-off-by: Grant Likely 
Cc: Darren Hart 
Cc: Jiri Kosina 
Cc: Benjamin Tissoires 
Cc: stable@vger.kernel.org
Tested-by: Darren Hart 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid into master

2020-07-17T16:43:13+00:00

Pull HID fixes from Jiri Kosina:

 - linked list race condition fix in hid-steam driver from Rodrigo Rivas
   Costa

 - assorted deviceID-specific quirks and other small cosmetic cleanups

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
  HID: logitech-hidpp: avoid repeated "multiplier = " log messages
  HID: logitech: Use HIDPP_RECEIVER_INDEX instead of 0xff
  HID: quirks: Ignore Simply Automated UPB PIM
  HID: apple: Disable Fn-key key-re-mapping on clone keyboards
  MAINTAINERS: update uhid and hid-wiimote entry
  HID: steam: fixes race in handling device list.
  HID: magicmouse: do not set up autorepeat
  HID: alps: support devices with report id 2
  HID: quirks: Always poll Obins Anne Pro 2 keyboard
  HID: i2c-hid: add Mediacom FlexBook edge13 to descriptor override

HID: logitech-hidpp: avoid repeated "multiplier = " log messages

2020-07-07T10:40:26+00:00

These messages appear each time the mouse wakes from sleep, in my case
(Logitech M705), every minute or so.
Let's downgrade them to the "debug" level so they don't fill the kernel log
by default.

While we are at it, let's make clear that this is a wheel multiplier (and
not, for example, XY movement multiplier).

Fixes: 4435ff2f09a2 ("HID: logitech: Enable high-resolution scrolling on Logitech mice")
Cc: stable@vger.kernel.org
Signed-off-by: Maciej S. Szmigiero 
Reviewed-by: Harry Cutts 
Signed-off-by: Jiri Kosina

HID: logitech: Use HIDPP_RECEIVER_INDEX instead of 0xff

2020-07-07T10:37:22+00:00

Some parts of hid-logitech-dj explicitly referred to 0xff for the
receiver index. This patch changes those references to the
HIDPP_RECEIVER_INDEX definition.

Signed-off-by: Mazin Rezk 
Reviewed-by: Filipe Laíns 
Signed-off-by: Jiri Kosina

HID: quirks: Ignore Simply Automated UPB PIM

2020-06-24T09:20:49+00:00

As this is a cypress HID->COM RS232 style device that is handled
by the cypress_M8 driver we also need to add it to the ignore list
in hid-quirks.

Cc: stable 
Signed-off-by: James Hilliard 
Signed-off-by: Jiri Kosina