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

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 <[email protected]>

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/[email protected]?part=1