Re: [PATCH v9] HID: steelseries: Add MSI Raider A18 HX A9WJG RGB support

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Potential out-of-bounds read in `steelseries_is_vendor_usage_page` when a malicious device provides a tiny report descriptor.
--

commit 45b36559149afdf0789fb9e7119bb71f74c98387
Author: David Glushkov <david.glushkov@sntiq.com>

HID: steelseries: Add MSI Raider A18 HX A9WJG RGB support

This commit adds DMI-gated support for the MSI Raider A18 HX A9WJG internal
SteelSeries USB HID devices for RGB lighting. It exposes them as multicolor
LED class devices and maps the ALC zones.

Closes: https://lore.kernel.org/oe-kbuild-all/202606010709.X0QYNjFZ-lkp@intel.com/

> diff --git a/drivers/hid/hid-steelseries.c b/drivers/hid/hid-steelseries.c
> index f98435631aa18..2eaa167455bba 100644
> --- a/drivers/hid/hid-steelseries.c
> +++ b/drivers/hid/hid-steelseries.c
[ ... ]
> @@ -528,6 +552,222 @@ static bool steelseries_is_vendor_usage_page(struct hid_device *hdev, uint8_t us
>  		hdev->rdesc[2] == 0xff;
>  }

[Severity: High]
This is a pre-existing issue, but can this read out of bounds if a malicious
device provides a tiny report descriptor?

The function steelseries_is_vendor_usage_page() unconditionally reads the
first 3 bytes of the report descriptor (hdev->rdesc[0..2]) when handling an
Arctis 9 device. The kernel's HID parsing logic allows report descriptors of
size 1 or 2.

If a malicious USB device supplies a 1- or 2-byte descriptor, the dynamically
allocated hdev->rdesc will be exactly that size. Reading hdev->rdesc[2]
accesses memory past the allocation, which could result in a
slab-out-of-bounds read and panic the kernel.

Could we add a check to verify hdev->rsize >= 3 before accessing the array?

> +
> +static const struct dmi_system_id steelseries_msi_rgb_dmi_table[] = {
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260605164133.14354-1-david.glushkov@sntiq.com?part=1