CVE-2026-64365: HID: letsketch: fix UAF on inrange_timer at driver unbind
In the Linux kernel, the following vulnerability has been resolved:
HID: letsketch: fix UAF on inrangetimer at driver unbind
letsketchdriver does not provide a .remove callback, but letsketchprobe() arms a per-device timer:
timersetup(&data->inrangetimer, letsketchinrangetimeout, 0);
The timer is re-armed from letsketchrawevent() with a 100 ms timeout on every pen-in-range report, and its callback dereferences data->inputtablet to deliver a synthetic BTNTOOLPEN release.
letsketchdata is allocated with devmkzalloc(), and its inputdev fields are devm-allocated via letsketchsetupinputtablet(). On device unbind (USB unplug or rmmod), the HID core runs its default teardown and devm cleanup frees both letsketchdata and the input devices. Because no .remove callback exists, nothing drains the timer first: if rawevent armed it within ~100 ms of the unbind, the pending timer fires on freed memory. This is a UAF read of data and of data->inputtablet, followed by inputreportkey() / inputsync() into the freed inputdev.
The same problem can occur on the probe error path: if hidhwstart() enabled I/O on an always-poll-quirk device and then failed, rawevent may have armed the timer before devm releases data.
Fix by adding a .remove callback that calls hidhwstop() first. hidhwstop() synchronously kills the URBs that deliver rawevent(), so once it returns no path can re-arm the timer. timershutdownsync() then drains any in-flight callback and permanently disables further modtimer() calls. Apply the same timershutdownsync() in the probe error path so the timer is guaranteed not to outlive data.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Implement a letsketch_driver .remove callback that calls hid_hw_stop() first, ensuring teardown stops HID hardware (synchronously kills in-flight URBs) before devm cleanup frees letsketch_data/input_dev.
Linux kernel HID letsketch driver .remove callback = Add .remove that calls hid_hw_stop() first - Configuration
Apply timer_shutdown_sync() behavior by ensuring the timer is drained/shutdown on failure paths so the inrange_timer cannot fire after letsketch_data is freed (UAF). Concretely, use timer_shutdown_sync() (or equivalent logic) where the timer may have been armed (e.g., probe error path after mod_timer/100 ms re-arming).
Linux kernel HID letsketch driver inrange_timer removal/drain handling = Call timer_shutdown_sync() in probe error path / ensure timer cannot outlive data
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux letsketch HID driver are exposed when a supported device is active and produces pen-in-range reports. The vulnerable condition can be triggered during device unbind, including USB unplug or driver removal, and may also occur on a probe error path after I/O has been enabled.
What conditions are needed to trigger the use-after-free?
A pen-in-range report must arm the driver's per-device timer, which is set for roughly 100 ms. If the device is unbound or the driver is removed before that timer expires, the timer can run after its device data and input device have been freed.
Is local access required?
Yes. The supplied CVSS vector identifies the attack vector as local and requires low privileges, with no user interaction. Exploitation also depends on access to the affected HID device or the ability to cause its driver to unbind.
What can be done if a fix cannot be deployed immediately?
Avoid unplugging or unbinding affected letsketch devices shortly after pen-in-range activity, and avoid removing the driver while such a device is in use. This reduces the opportunity for the pending 100 ms timer to fire after teardown, but does not eliminate the underlying flaw.