Re: [PATCH v2 3/4] hwmon: (asus_rog_ryujin) Add ROG Ryujin III White Edition

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Missing bounds check on incoming HID report size in `rog_ryujin_raw_event` leading to an out-of-bounds heap read.
--

--- Patch [3]: [PATCH v2 3/4] hwmon: (asus_rog_ryujin) Add ROG Ryujin III White Edition ---
commit b585240116bcd8eafe7d693a9003f8ad82dee763
Author: Will Smith <github@notthatwillsmith.com>

hwmon: (asus_rog_ryujin) Add ROG Ryujin III White Edition

The ROG Ryujin III White Edition uses the same report layout as the
other supported Ryujin III variants. Add its USB device ID and list it
in the driver documentation.

Link: https://github.com/aleksamagicka/asus_rog_ryujin-hwmon/pull/10

> diff --git a/drivers/hwmon/asus_rog_ryujin.c b/drivers/hwmon/asus_rog_ryujin.c
> index 5bc60c6036de3..9b34c6e06bf78 100644
> --- a/drivers/hwmon/asus_rog_ryujin.c
> +++ b/drivers/hwmon/asus_rog_ryujin.c

[ ... ]

> @@ -587,6 +588,8 @@ static const struct hid_device_id rog_ryujin_table[] = {
>  	  .driver_data = (kernel_ulong_t)&rog_ryujin_iii_info },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUS_ROG, USB_PRODUCT_ID_RYUJIN_III_EVA),
>  	  .driver_data = (kernel_ulong_t)&rog_ryujin_iii_info },
> +	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUS_ROG, USB_PRODUCT_ID_RYUJIN_III_WHITE),
> +	  .driver_data = (kernel_ulong_t)&rog_ryujin_iii_info },

[Severity: High]
This is a pre-existing issue, but adding this device ID exposes the new
hardware to a missing bounds check in rog_ryujin_raw_event().

When the driver receives raw HID reports, it fails to validate the incoming
size parameter against the offsets it accesses:

drivers/hwmon/asus_rog_ryujin.c:rog_ryujin_raw_event() {
	...
	if (data[0] != RYUJIN_CMD_PREFIX)
		return 0;

	if (data[1] == RYUJIN_GET_COOLER_STATUS_CMD_RESPONSE) {
		/* Received coolant temp and speeds of pump and internal fan */
		priv->temp_input[0] = data[priv->info->temp_offset] * 1000 +
			data[priv->info->temp_offset + 1] * 100;
	...
}

If a malicious USB device presents a HID descriptor declaring a very small
report size (e.g., 1 byte) and sends a 1-byte report, the driver
unconditionally accesses fixed offsets such as data[1] and, depending on the
device info, up to data[12].

Could this allow an out-of-bounds heap read where leaked kernel memory is
stored in variables like priv->temp_input and priv->speed_input, and then
exposed to userspace via the hwmon sysfs interface?

>  	{ }
>  };
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260811233943.319729-1-renari@arimil.com?part=3