Re: [PATCH] HID: corsair-void: Fix firmware event packet description

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The `corsair_void_raw_event()` function lacks a bounds check on the `size` of the incoming HID report, which can lead to an out-of-bounds read when accessing elements up to `data[4]`.
--

commit d2f977ace02628f486f8135ff442479be032fad6
Author: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>

HID: corsair-void: Fix firmware event packet description

This commit updates the comment describing the firmware event packet in the
corsair-void HID driver. It corrects the stated size to 5 bytes to include
the ID, and updates the corresponding indices for the firmware versions.

> diff --git a/drivers/hid/hid-corsair-void.c b/drivers/hid/hid-corsair-void.c
> index 5e9a5b8f7f167..ce92e3a9c0580 100644
> --- a/drivers/hid/hid-corsair-void.c
> +++ b/drivers/hid/hid-corsair-void.c
> @@ -51,20 +51,23 @@
>  /* Receiver report information: (ID 102)                                      */
>  /* -------------------------------------------------------------------------- */
>  /*
> - * When queried, the recevier responds with 4 bytes to describe the firmware
> - * The first 2 bytes are for the receiver, the second 2 are the headset
> + * When queried, the receiver responds with 5 bytes to describe the firmware
> + * The first byte is the ID, then 2 bytes for the receiver, then 2 for the headset
>   * The headset firmware version will be 0 if no headset is connected
>   *
> - * 0: Recevier firmware major version
> + * 0: Report ID
> + *  102 for the firmware packet
> + *
> + * 1: Receiver firmware major version
>   *  Major version of the receiver's firmware
>   *
> - * 1: Recevier firmware minor version
> + * 2: Receiver firmware minor version
>   *  Minor version of the receiver's firmware
>   *
> - * 2: Headset firmware major version
> + * 3: Headset firmware major version
>   *  Major version of the headset's firmware
>   *
> - * 3: Headset firmware minor version
> + * 4: Headset firmware minor version
>   *  Minor version of the headset's firmware
>   */

[Severity: High]
This is a pre-existing issue, but does corsair_void_raw_event() lack a bounds
check on the size of the incoming HID report?

When the device sends a report matching the firmware report ID, it appears
the handler unconditionally accesses elements up to data[4]:

drivers/hid/hid-corsair-void.c:corsair_void_raw_event() {
    ...
    drvdata->fw_receiver_major = data[1];
    drvdata->fw_receiver_minor = data[2];
    drvdata->fw_headset_major = data[3];
    drvdata->fw_headset_minor = data[4];
    ...
}

If a malicious USB device sends a crafted HID descriptor defining a small
maximum report size, and then sends a 1-byte firmware report, can this lead
to an out-of-bounds read past the end of the report buffer?

It looks like the same issue might exist for the status report, which also
reads up to data[4] unconditionally:

drivers/hid/hid-corsair-void.c:corsair_void_raw_event() {
    ...
    drvdata->mic_up = FIELD_GET(CORSAIR_VOID_MIC_MASK, data[2]);
    drvdata->connected = (data[3] == CORSAIR_VOID_WIRELESS_CONNECTED) ||
                 drvdata->is_wired;

    corsair_void_process_receiver(drvdata,
                  FIELD_GET(CORSAIR_VOID_CAPACITY_MASK, data[2]),
                  data[3], data[4]);
    ...
}

Could these out-of-bounds bytes be subsequently exposed to userspace via
sysfs attributes, resulting in a kernel memory information leak?

Could this also potentially trigger a kernel panic if the dynamically
allocated report buffer is small?

>  /* -------------------------------------------------------------------------- */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630004323.589696-3-stuart.a.hayhurst@gmail.com?part=1