CVE-2026-64365

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: letsketch: fix UAF on inrange_timer at driver unbind<br /> <br /> letsketch_driver does not provide a .remove callback, but<br /> letsketch_probe() arms a per-device timer:<br /> <br /> timer_setup(&amp;data-&gt;inrange_timer, letsketch_inrange_timeout, 0);<br /> <br /> The timer is re-armed from letsketch_raw_event() with a 100 ms<br /> timeout on every pen-in-range report, and its callback dereferences<br /> data-&gt;input_tablet to deliver a synthetic BTN_TOOL_PEN release.<br /> <br /> letsketch_data is allocated with devm_kzalloc(), and its input_dev<br /> fields are devm-allocated via letsketch_setup_input_tablet(). On<br /> device unbind (USB unplug or rmmod), the HID core runs its default<br /> teardown and devm cleanup frees both letsketch_data and the input<br /> devices. Because no .remove callback exists, nothing drains the<br /> timer first: if raw_event armed it within ~100 ms of the unbind,<br /> the pending timer fires on freed memory. This is a UAF read of<br /> data and of data-&gt;input_tablet, followed by input_report_key() /<br /> input_sync() into the freed input_dev.<br /> <br /> The same problem can occur on the probe error path: if<br /> hid_hw_start() enabled I/O on an always-poll-quirk device and then<br /> failed, raw_event may have armed the timer before devm releases<br /> data.<br /> <br /> Fix by adding a .remove callback that calls hid_hw_stop() first.<br /> hid_hw_stop() synchronously kills the URBs that deliver raw_event(),<br /> so once it returns no path can re-arm the timer. timer_shutdown_sync()<br /> then drains any in-flight callback and permanently disables further<br /> mod_timer() calls. Apply the same timer_shutdown_sync() in the probe<br /> error path so the timer is guaranteed not to outlive data.