[PATCH] HID: huawei/rapoo: reject non-USB transports before to_usb_interface()

[PATCH] HID: huawei/rapoo: reject non-USB transports before to_usb_interface()

[Jiale Yao]

hid-huawei's huawei_report_fixup() unconditionally calls
to_usb_interface(hdev->dev.parent) without first verifying the
device is actually a USB HID device.  When uhid spoofs bus = BUS_USB
with matching VID/PID, hdev->dev.parent points to a uhid_device,
not a usb_interface.  to_usb_interface() returns a garbage pointer,
triggering:

  BUG: KASAN: slab-out-of-bounds in huawei_report_fixup
  Read of size 8 at 1176 bytes beyond an 800-byte kmalloc-1k region
  BUG: KASAN: null-ptr-deref in huawei_report_fixup

  Call Trace:
   huawei_report_fixup
   hid_open_report
   hid_device_probe
   really_probe
   uhid_device_add_worker

hid-rapoo's rapoo_probe() guards the to_usb_interface() call with
hdev->bus == BUS_USB, but uhid can forge hdev->bus, trivially
bypassing this check and causing the same type confusion.

Fix both drivers by adding the proper hid_is_usb() guard -- a helper
that inspects the actual parent device type rather than trusting the
forgeable bus field -- before any to_usb_interface() dereference.

Fixes: e93faaca84b7 ("HID: huawei: fix CD30 keyboard report descriptor issue")
Fixes: b3b1c68fb726 ("HID: rapoo: Add support for side buttons on RAPOO 0x2015 mouse")
Assisted-by: Claude:deepseek-v4-pro
Signed-off-by: Jiale Yao <yaojiale02@163.com>
---
 drivers/hid/hid-huawei.c | 7 ++++++-
 drivers/hid/hid-rapoo.c  | 2 +-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-huawei.c b/drivers/hid/hid-huawei.c
index 6a616bf21b38..d2f9f15871a2 100644
--- a/drivers/hid/hid-huawei.c
+++ b/drivers/hid/hid-huawei.c
@@ -44,7 +44,12 @@ static const __u8 huawei_cd30_kbd_rdesc_fixed[] = {
 static const __u8 *huawei_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 				  unsigned int *rsize)
 {
-	struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
+	struct usb_interface *intf;
+
+	if (!hid_is_usb(hdev))
+		return rdesc;
+
+	intf = to_usb_interface(hdev->dev.parent);
 
 	switch (hdev->product) {
 	case USB_DEVICE_ID_HUAWEI_CD30KBD:
diff --git a/drivers/hid/hid-rapoo.c b/drivers/hid/hid-rapoo.c
index 4c81f3086de4..5c9c396fabf7 100644
--- a/drivers/hid/hid-rapoo.c
+++ b/drivers/hid/hid-rapoo.c
@@ -36,7 +36,7 @@ static int rapoo_probe(struct hid_device *hdev, const struct hid_device_id *id)
 		return ret;
 	}
 
-	if (hdev->bus == BUS_USB) {
+	if (hid_is_usb(hdev)) {
 		struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
 
 		if (intf->cur_altsetting->desc.bInterfaceNumber != 1)
-- 
2.34.1

Re: [PATCH] HID: huawei/rapoo: reject non-USB transports before to_usb_interface()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] Missing Kconfig dependency on USB_HID for HID_RAPOO leads to undefined reference link errors.

Pre-existing issues:
- [High] Type confusion vulnerability in `hid-asus.c` remains unpatched.
- [Medium] Resource leak due to missing `hid_hw_stop()` on error paths in `rapoo_probe`.
--

--- Patch [1]: [PATCH] HID: huawei/rapoo: reject non-USB transports before to_usb_interface() ---
commit 1c01c51fb3ab417da0ea9ad5aa2162a46f5fc7cd
Author: Jiale Yao <yaojiale02@163.com>

HID: huawei/rapoo: reject non-USB transports before to_usb_interface()

This commit fixes a type confusion vulnerability in the hid-huawei and
hid-rapoo drivers by verifying that the device is actually a USB device
using hid_is_usb() before dereferencing the parent as a usb_interface.
This prevents spoofing attacks from uhid devices that forge the bus type.

> diff --git a/drivers/hid/hid-rapoo.c b/drivers/hid/hid-rapoo.c
> index 4c81f3086de43..5c9c396fabf77 100644
> --- a/drivers/hid/hid-rapoo.c
> +++ b/drivers/hid/hid-rapoo.c
> @@ -36,7 +36,7 @@ static int rapoo_probe(struct hid_device *hdev, const struct hid_device_id *id)
>  		return ret;
>  	}
>  
> -	if (hdev->bus == BUS_USB) {
> +	if (hid_is_usb(hdev)) {

[Severity: High]
Does this new call to hid_is_usb() require updating drivers/hid/Kconfig to
add a dependency on USB_HID for config HID_RAPOO?

If the kernel is compiled with CONFIG_HID_RAPOO=y and CONFIG_USB_HID=m
(or n), wouldn't this cause a build failure during final vmlinux linkage
since hid_is_usb() is implemented and exported by the usbhid module?

[Severity: Medium]
This is a pre-existing issue, but does rapoo_probe() fail to clean up
the started hardware on error paths?

If devm_input_allocate_device() or input_register_device() fail later in
this function, the code returns directly without calling hid_hw_stop():

drivers/hid/hid-rapoo.c:rapoo_probe() {
    ...
    ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
    ...
    if (hid_is_usb(hdev)) {
    ...
    input = devm_input_allocate_device(&hdev->dev);
    if (!input)
        return -ENOMEM;
    ...
}

Since hid_hw_start() was successfully called earlier, does this leave the
device in an active but unbound state when those allocations fail?

[Severity: High]
This is a pre-existing issue, but is the asus driver vulnerable to the same
type confusion being fixed here?

Looking at asus_kbd_register_leds() in drivers/hid/hid-asus.c, the code casts
to a usb_interface without verifying if the underlying transport is actually
USB:

drivers/hid/hid-asus.c:asus_kbd_register_leds() {
    ...
    if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
        intf = to_usb_interface(hdev->dev.parent);
        udev = interface_to_usbdev(intf);
    ...
}

If an attacker injects a spoofed device via /dev/uhid matching the ASUS ROG
ALLY vendor and product IDs, couldn't this trigger the exact same KASAN
slab-out-of-bounds read or panic when interface_to_usbdev() dereferences
the uhid parent?

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