Re: [PATCH] HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()

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

Pre-existing issues:
- [High] A 1-byte out-of-bounds heap read occurs in `wacom_wac_pen_serial_enforce` when processing an unnumbered HID report.
--

--- Patch [1]: [PATCH] HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce() ---
commit 7eb0a702b27b2b8dba9547945aa50ecb4a4d7cc0
Author: Wei Jie Law <[email protected]>

HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()

This commit fixes an out-of-bounds read in wacom_wac_pen_serial_enforce()
by clamping the usage iteration count to the field's actual report count.
This prevents extracting data beyond the received report bounds when a
descriptor lists more usages than its Report Count.

> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 0eafa483b7f75..1ea8763b68a82 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -113,8 +113,10 @@ static int wacom_wac_pen_serial_enforce(struct hid_device *hdev,
>  
>  	/* Queue events which have invalid tool type or serial number */
>  	for (i = 0; i < report->maxfield; i++) {
> -		for (j = 0; j < report->field[i]->maxusage; j++) {
> -			struct hid_field *field = report->field[i];
> +		struct hid_field *field = report->field[i];
> +		unsigned int count = min(field->maxusage, field->report_count);
> +
> +		for (j = 0; j < count; j++) {
>  			struct hid_usage *usage = &field->usage[j];
>  			unsigned int equivalent_usage = wacom_equivalent_usage(usage->hid);
>  			unsigned int offset;

[Severity: High]
This isn't a bug introduced by this patch, but does the call to
hid_field_extract() later in this loop cause an out-of-bounds read if the
report is unnumbered?

Inside the loop, the code calls:

	value = hid_field_extract(hdev, raw_data+1, offset + j * size, size);

This blindly adds 1 to raw_data, assuming raw_data[0] is a report ID. If an
attacker crafts a USB HID device (or uses UHID) with the Wacom vendor ID
(0x056a) but provides a descriptor with no Report ID, the transport layer
allocates a buffer exactly matching the payload size.

For the last field in such an unnumbered report, this reads 1 byte past the
end of the heap allocation. Since the extracted value can be stored in
wacom_wac->serial[0] and emitted to userspace via MSC_SERIAL events, could
this lead to a 1-byte out-of-bounds heap read and information disclosure?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1