Re: [PATCH v2] HID: rmi: fix use-after-free of struct rmi_data via reset_work

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Out-of-bounds read in `rmi_hid_read_block()` due to unvalidated device input.
- [High] Global state contamination in `rmi_probe()` affecting subsequently probed devices.
--

--- Patch [1]: [PATCH v2] HID: rmi: fix use-after-free of struct rmi_data via reset_work ---
commit 9830b0c9b8478c73372950d4bfd3441d196438f1
Author: Wei Jie Law <98lawweijie@gmail.com>

HID: rmi: fix use-after-free of struct rmi_data via reset_work

This patch resolves a use-after-free vulnerability involving struct rmi_data
and its reset_work. It unconditionally cancels the work in rmi_remove() and
prevents new work from being queued inappropriately during device removal.

> diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
> index 2bd781f1e0f53..4df6d8cd2dc3c 100644
> --- a/drivers/hid/hid-rmi.c
> +++ b/drivers/hid/hid-rmi.c

[ ... ]

drivers/hid/hid-rmi.c:rmi_hid_read_block() {
    ...
			read_input_count = data->readReport[1];
			memcpy(buf + bytes_read, &data->readReport[2],
				min(read_input_count, bytes_needed));
    ...
}

[Severity: High]
This isn't a bug introduced by this patch, but can this code cause an
out-of-bounds read?

A malicious device could advertise a small input_report_size via its HID
descriptor but send an input report with a large length field in data[1].

Because rmi_hid_read_block() uses this untrusted data->readReport[1] as
read_input_count, could it bypass boundary checks against the buffer's
actual allocated size during the memcpy?


drivers/hid/hid-rmi.c:rmi_probe() {
    ...
	if (data->device_flags & RMI_DEVICE_HAS_PHYS_BUTTONS)
		rmi_hid_pdata.gpio_data.disable = true;

	data->xport.dev = hdev->dev.parent;
	data->xport.pdata = rmi_hid_pdata;
    ...
}

[Severity: High]
This isn't a bug introduced by this patch, but does this code modify the
global static rmi_hid_pdata struct instead of a device-specific local copy?

If a device with the RMI_DEVICE_HAS_PHYS_BUTTONS flag is probed, it sets
gpio_data.disable = true on the global struct.

If a different RMI device without this flag is subsequently probed on the
same system, could it incorrectly inherit the disabled GPIO state from this
contaminated global template?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260825103144.12356-1-98lawweijie@gmail.com?part=1