Re: [PATCH] HID: wacom: validate GRAPHIRE_BT report length

[Aamir Ahmed]

On Sat, Sep 05, 2026 at 10:29:08AM +0000, Sashiko AI wrote:
> [Severity: High]
> This is a pre-existing issue, but is there a missing cancellation of
> asynchronous timers and workqueues in the wacom_probe() error path?

Partly. I checked this and the core of it is real, but narrower than
described.

The only work item that can be pending when wacom_parse_and_register()
fails is init_work. wacom_query_tablet_data() schedules it one second
out before the WL_MONITOR hid_hw_open() call, and if that call fails the
error path does not cancel it. wacom_probe() then returns the error,
__hid_device_probe() releases the devres group and frees the wacom
structure, and wacom_init_work() runs on freed memory a second later.

wireless_work, battery_work, remote_work and the timers cannot be
involved. They are only scheduled from incoming reports, and
__hid_input_report() drops every report while probe() holds
driver_input_lock, which this driver never releases early.

It is also not reachable from user input: it needs one of two devices
and hid_hw_open() failing at that moment, so I would not call it High.
I have sent a fix as a separate patch:

  HID: wacom: Cancel init_work when probe fails after scheduling it

> This isn't a bug introduced by this patch, but does this bounds check
> mistakenly limit itself to GRAPHIRE_BT devices?

The other device types served by wacom_graphire_irq() are USB, where
the transport buffer is at least 64 bytes, so a short report yields
stale bytes from the previous report rather than an out-of-bounds
read. The same applies to wacom_intuos_irq(). Extending the checks
would be reasonable hardening, and I am happy to send that separately
if the maintainers want it, but it is not a memory safety fix.

Thanks,
Aamir