Re: [PATCH] HID: lenovo: Fix buffer over-read in X12 Tab raw_event handler

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unaligned memory access via direct pointer cast in raw event handler.
- [High] Missing input capability registration causes hotkey events to be silently dropped.
--

commit a1525e53f7f5fe161ed804808d59755ff69c771f
Author: Kean <rh_king@163.com>

HID: lenovo: Fix buffer over-read in X12 Tab raw_event handler

In lenovo_raw_event(), the X12 Tab keyboard handler reads a 4-byte
little-endian value via *(__le32 *)data but only guards the access
with a size >= 3 check. If a 3-byte report with ID 0x03 is received,
the code reads one byte beyond the end of the buffer.
    
Change the size check to >= 4 to match the actual access width.

> diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
> index a6b73e03c16b3..4686ecb6cfa8e 100644
> --- a/drivers/hid/hid-lenovo.c
> +++ b/drivers/hid/hid-lenovo.c
> @@ -793,7 +793,7 @@ static int lenovo_raw_event(struct hid_device *hdev,
>  	 */
>  	if (unlikely((hdev->product == USB_DEVICE_ID_LENOVO_X12_TAB
>  			|| hdev->product == USB_DEVICE_ID_LENOVO_X12_TAB2)
> -			&& size >= 3 && report->id == 0x03))
> +			&& size >= 4 && report->id == 0x03))
>  		return lenovo_raw_event_TP_X12_tab(hdev, le32_to_cpu(*(__le32 *)data));

This isn't a regression from this patch, but could this direct pointer cast
lead to unaligned memory access exceptions?

The data pointer provided by the HID core can have arbitrary alignment
depending on the transport layer. For instance, if injected via uhid using
UHID_INPUT2, the payload data starts at an offset of 6 bytes from the start
of the uhid_event struct, which is 2-byte aligned but not 4-byte aligned.

On architectures that do not natively support unaligned memory access,
dereferencing an unaligned pointer triggers an unaligned access exception.

Would it be safer to use get_unaligned_le32(data) to safely extract the
value?

Also, another issue not introduced by this patch: do the hotkey events
processed by lenovo_raw_event_TP_X12_tab() get silently dropped by the input
core?

The lenovo_raw_event_TP_X12_tab() handler reports events for keys like
KEY_RFKILL, KEY_PERFORMANCE, and KEY_BOOKMARKS:

drivers/hid/hid-lenovo.c:lenovo_raw_event_TP_X12_tab() {
	...
	case TP_X12_RAW_HOTKEY_FN_F8:
		if (hdev->product == USB_DEVICE_ID_LENOVO_X12_TAB) {
			report_key_event(input, KEY_RFKILL);
			return 1;
		}
		report_key_event(input, KEY_PERFORMANCE);
		return 1;
	...
}

However, if these key capabilities are not registered in the input_dev's
keybit array during device initialization, the kernel's input core checks
is_event_supported(code, dev->keybit, KEY_MAX) and drops the events when
report_key_event() is called.

Are these custom hotkey capabilities properly registered during device setup
to prevent them from being filtered out?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511132854.1351379-1-rh_king@163.com?part=1