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

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Delayed work 'init_work' is scheduled but not canceled on hid_hw_open() failure, leading to Use-After-Free.
- [High] Sysfs handlers wacom_led_select_store and wacom_led_select_show do not check if wacom->led.groups is NULL before accessing it, leading to a crash during unbind.
--

commit e33281ca5de90c5a4993fe522ad3163d519fa468
Author: Wei Jie Law <98lawweijie@gmail.com>

HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()

This commit clamps the iteration loop in wacom_wac_pen_serial_enforce() to
field->report_count to prevent an out-of-bounds read when processing usages.
It fixes an information disclosure bug where reports could read past their
bounds into other memory.

[ ... ]

drivers/hid/wacom_sys.c:wacom_parse_and_register()
> 		error = hid_hw_open(hdev);
> 		if (error) {
> 			hid_err(hdev, "hw open failed\n");
> 			goto fail_hw_stop;
> 		}

[Severity: High]
This is a pre-existing issue, and was not introduced by the patch under
review, but does this error path fail to cancel the previously scheduled
init_work before returning?

A device connects and wacom_probe() calls wacom_parse_and_register().
The function schedules wacom->init_work.

If the device is a WL_MONITOR and hid_hw_open() fails, the function exits
with an error without canceling the delayed work. 

The HID core's devres cleanup frees the wacom structure, leaving the delayed
work queued.

Could this cause a Use-After-Free memory corruption when the delayed work
executes after the wacom structure has been freed?

A malicious USB device or a fuzzer could simulate a device that fails
hid_hw_open(), reliably triggering the use-after-free.

[ ... ]

drivers/hid/wacom_sys.c:wacom_led_select_store()
> 	wacom->led.groups[set_id].select = id & 0x3;

[Severity: High]
This is a pre-existing issue, and was not introduced by the patch under
review, but could this assignment cause a NULL pointer dereference of
wacom->led.groups?

During device unbind, wacom_remove() clears wacom->led.groups to NULL. Because
the sysfs attributes were created using devres (sysfs_create_group), they are
not removed until after wacom_remove() completes. 

During this window, any read or write to status_ledX_select will invoke
wacom_led_select_show() or wacom_led_select_store(), which unconditionally
dereference wacom->led.groups.

drivers/hid/wacom_sys.c:wacom_led_select_show()
> 	return scnprintf(buf, PAGE_SIZE, "%d\n",			\
> 			 wacom->led.groups[SET_ID].select);		\

[Severity: High]
This is a pre-existing issue, and was not introduced by the patch under
review, but is wacom->led.groups accessed here without first checking if it
is NULL?

Could this lead to a NULL pointer dereference and a kernel crash?

The sysfs files are world-readable (DEV_ATTR_RW_PERM), meaning an unprivileged
local user can continuously read them in a loop while the device is being
unplugged to win the race and crash the system.

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