BMC/Intel-BMC/linux.git/drivers/hid/hid-core.c, branch dev-5.10-intel

HID: do not use down_interruptible() when unbinding devices

2021-07-14T14:55:57+00:00

[ Upstream commit f2145f8dc566c4f3b5a8deb58dcd12bed4e20194 ] Action of unbinding driver from a device is not cancellable and should not fail, and driver core does not pay attention to the result of "remove" method, therefore using down_interruptible() in hid_device_remove() does not make sense. Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: Add BUS_VIRTUAL to hid_connect logging

2021-06-18T08:00:03+00:00

[ Upstream commit 48e33befe61a7d407753c53d1a06fc8d6b5dab80 ] Add BUS_VIRTUAL to hid_connect logging since it's a valid hid bus type and it should not print Signed-off-by: Mark Bolhuis Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: core: detect and skip invalid inputs to snto32()

2021-03-04T10:37:54+00:00

[ Upstream commit a0312af1f94d13800e63a7d0a66e563582e39aec ] Prevent invalid (0, 0) inputs to hid-core's snto32() function. Maybe it is just the dummy device here that is causing this, but there are hundreds of calls to snto32(0, 0). Having n (bits count) of 0 is causing the current UBSAN trap with a shift value of 0xffffffff (-1, or n - 1 in this function). Either of the value to shift being 0 or the bits count being 0 can be handled by just returning 0 to the caller, avoiding the following complex shift + OR operations: return value & (1 << (n - 1)) ? value | (~0U << n) : value; Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split") Signed-off-by: Randy Dunlap Reported-by: syzbot+1e911ad71dd4ea72e04a@syzkaller.appspotmail.com Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: linux-input@vger.kernel.org Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: make arrays usage and value to be the same

2021-02-26T09:12:59+00:00

commit ed9be64eefe26d7d8b0b5b9fa3ffdf425d87a01f upstream. The HID subsystem allows an "HID report field" to have a different number of "values" and "usages" when it is allocated. When a field struct is created, the size of the usage array is guaranteed to be at least as large as the values array, but it may be larger. This leads to a potential out-of-bounds write in __hidinput_change_resolution_multipliers() and an out-of-bounds read in hidinput_count_leds(). To fix this, let's make sure that both the usage and value arrays are the same size. Cc: stable@vger.kernel.org Signed-off-by: Will McVicker Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-5.9/upstream-fixes' into for-linus

2020-10-15T18:41:43+00:00

- "heartbeat" report fix for several Wacom devices - Lenovo X1 Tablet support improvements - new device IDs - bounds checking fix in hid-roccat - stylus battery reporting fix

HID: add vivaldi HID driver

2020-09-30T20:44:26+00:00

Add vivaldi HID driver. This driver allows us to read and report the top row layout of keyboards which provide a vendor-defined (Google) HID usage. Signed-off-by: Sean O'Brien Signed-off-by: Jiri Kosina

HID: core: fix kerneldoc warnings in hid-core.c

2020-09-23T11:10:45+00:00

Fix following warnings caused by mismatch bewteen function parameters and comments. drivers/hid/hid-core.c:931: warning: Function parameter or member 'hid' not described in 'hid_parse_report' drivers/hid/hid-core.c:931: warning: Excess function parameter 'device' description in 'hid_parse_report' drivers/hid/hid-core.c:961: warning: Function parameter or member 'hid' not described in 'hid_validate_values' drivers/hid/hid-core.c:961: warning: Excess function parameter 'device' description in 'hid_validate_values' drivers/hid/hid-core.c:1452: warning: Function parameter or member 'report' not described in 'hid_match_report' drivers/hid/hid-core.c:1452: warning: Excess function parameter 'report_type' description in 'hid_match_report' drivers/hid/hid-core.c:2132: warning: Function parameter or member 'drv' not described in 'new_id_store' drivers/hid/hid-core.c:2132: warning: Excess function parameter 'driver' description in 'new_id_store' Signed-off-by: Xiaofei Tan Signed-off-by: Jiri Kosina

HID: core: Correctly handle ReportSize being zero

2020-09-01T08:25:49+00:00

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

HID: core: fix off-by-one memset in hid_report_raw_event()

2020-02-12T13:18:33+00:00

In case a report is greater than HID_MAX_BUFFER_SIZE, it is truncated, but the report-number byte is not correctly handled. This results in a off-by-one in the following memset, causing a kernel Oops and ensuing system crash. Note: With commit 8ec321e96e05 ("HID: Fix slab-out-of-bounds read in hid_field_extract") I no longer hit the kernel Oops as we instead fail "controlled" at probe if there is a report too long in the HID report-descriptor. hid_report_raw_event() is an exported symbol, so presumabely we cannot always rely on this being the case. Fixes: 966922f26c7f ("HID: fix a crash in hid_report_raw_event() function.") Signed-off-by: Johan Korsnes Cc: Armando Visconti Cc: Jiri Kosina Cc: Alan Stern Signed-off-by: Jiri Kosina

HID: Fix slab-out-of-bounds read in hid_field_extract

2019-12-11T14:17:39+00:00

The syzbot fuzzer found a slab-out-of-bounds bug in the HID report handler. The bug was caused by a report descriptor which included a field with size 12 bits and count 4899, for a total size of 7349 bytes. The usbhid driver uses at most a single-page 4-KB buffer for reports. In the test there wasn't any problem about overflowing the buffer, since only one byte was received from the device. Rather, the bug occurred when the HID core tried to extract the data from the report fields, which caused it to try reading data beyond the end of the allocated buffer. This patch fixes the problem by rejecting any report whose total length exceeds the HID_MAX_BUFFER_SIZE limit (minus one byte to allow for a possible report index). In theory a device could have a report longer than that, but if there was such a thing we wouldn't handle it correctly anyway. Reported-and-tested-by: syzbot+09ef48aa58261464b621@syzkaller.appspotmail.com Signed-off-by: Alan Stern CC: Signed-off-by: Jiri Kosina