Re: [PATCH 13/15] HID: hid-oxp: represent RGB LEDs with a common array

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Invalid cast to `usb_interface` without validating the transport via `hid_is_usb()`.
--

commit 4292fdde3cbe4b16ea52c7763677a6325b071bca
Author: Andrei Aldea <andrei1998@gmail.com>

HID: hid-oxp: represent RGB LEDs with a common array

Move the existing joystick-ring class device, color components, delayed
work, and cached settings into a per-LED wrapper owned by each HID
configuration. Use a tagged state pointer so later LED types can share
registration and work management without duplicating the lifecycle.

> diff --git a/drivers/hid/hid-oxp.c b/drivers/hid/hid-oxp.c
> index 48fa9169b84c7..55f8b4773e334 100644
> --- a/drivers/hid/hid-oxp.c
> +++ b/drivers/hid/hid-oxp.c

[Severity: High]
This isn't a bug introduced by this patch (it was added earlier in the
series in patch 12/15), but it remains unfixed in the final state.

Does this code perform an invalid cast if the device is a virtual HID device?
In oxp_is_cfg_interface():

	if (hdev->bus != BUS_USB)
		return false;

	intf = to_usb_interface(hdev->dev.parent);

If a malicious or buggy user-space application (e.g. via uhid) creates a
virtual HID device with BUS_USB, the parent device is the uhid character
device, not a USB interface.

Since the code does not validate the transport via hid_is_usb(), doesn't
this unconditional cast lead to type confusion and an out-of-bounds memory
read?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910032115.28669-1-andrei1998@gmail.com?part=13