CVE-2026-64365

What it actually does

This is a Linux kernel use-after-free in the HID letsketch driver. The driver arms a per-device timer when pen-in-range HID reports are received, but older vulnerable code does not cancel and drain that timer before device teardown. During USB unplug, driver unbind, module removal, or certain probe-failure paths, devm-managed driver state and input device structures can be freed while the timer is still pending. If the timer fires afterward, it dereferences freed memory and calls input_report_key()/input_sync() against a freed input device. The most likely impact is kernel memory corruption and system crash; depending on allocator state, kernel hardening, and attacker control over replacement allocations, exploitation may theoretically support privilege escalation or arbitrary kernel behavior, but no public exploit maturity is currently indicated.

Why it matters to the business

Systems that load the affected Linux HID driver and accept untrusted or attacker-controlled USB/HID devices could be crashed or destabilized through device interaction and timing. The operational risk is highest for workstations, kiosks, shared terminals, lab machines, point-of-sale systems, or production hosts where physical USB access, peripheral pass-through, or untrusted device attachment is possible. The current EPSS is low and the issue is not listed in CISA KEV, so broad internet-scale exploitation is unlikely; however, kernel memory-safety flaws should still be prioritized where local device access is plausible or where system availability is critical.

How an attack unfolds

An attacker needs a path to present a Letsketch-compatible HID device, or a malicious USB/HID device that can exercise the same driver path, to a vulnerable Linux system. The device sends pen-in-range reports that cause letsketch_raw_event() to arm the inrange_timer with a short timeout. The attacker then causes device teardown before that timer expires, such as by unplugging the device, triggering HID driver unbind, or racing a probe failure path. Because vulnerable kernels do not provide a remove callback that stops I/O and synchronously shuts down the timer, devm cleanup can free the letsketch_data structure and associated input_dev objects while the timer is still pending. When the timer fires, it uses those freed objects to report a synthetic pen-release event, resulting in use-after-free access in kernel context. In practical terms, this is most likely to produce a kernel oops, panic, or host instability; reliable code execution would require additional heap shaping and bypasses and is not known to be publicly available.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the HID letsketch driver. The fix adds a remove callback that calls hid_hw_stop() to stop incoming HID events and then uses timer_shutdown_sync() to drain and permanently disable the timer before devm-managed memory is released; it also applies timer_shutdown_sync() on the probe error path. If a patched kernel is not immediately available, reduce exposure by preventing untrusted USB/HID device attachment, disabling or removing the affected HID driver where not needed, restricting module loading and driver unbind operations to trusted administrators, and applying USB device allowlisting through mechanisms such as USBGuard or equivalent endpoint controls. Because no exact fixed package versions were provided, use the kernel vendor’s advisory or distribution errata for the authoritative patched version for each deployed kernel stream.

How to confirm the fix worked

Confirm that deployed kernels include the HID letsketch fix by checking the vendor changelog, source package, or kernel commit history for the letsketch driver change that adds a .remove callback and calls hid_hw_stop() followed by timer_shutdown_sync(), including the corresponding probe error-path cleanup. Validate running exposure by identifying systems with the affected kernel version and the letsketch HID driver available or loaded. Where safe and authorized, verify that unbinding or unplugging a Letsketch-compatible device after pen-in-range activity no longer produces kernel oops, use-after-free reports, KASAN findings, lockups, or panic messages. Also confirm that endpoint controls prevent unauthorized HID devices from binding to the driver on systems where the device class is not required.

Typical attack path

1. Gain physical, peripheral, USB-over-IP, VM USB pass-through, or other local ability to attach a HID device to the target Linux system.
2. Present a Letsketch-compatible HID device or emulate the expected HID reports so the Linux letsketch HID driver binds to the device.
3. Send pen-in-range reports that cause the driver to arm or re-arm the per-device inrange_timer.
4. Trigger device teardown within the timer window, for example by unplugging the device, forcing driver unbind, or racing an error path during probe.
5. Allow the pending timer callback to execute after driver-managed memory and input device structures have been freed.
6. Cause kernel use-after-free behavior, typically resulting in a crash, panic, or other instability, with potential for more severe impact under favorable exploitation conditions.

How to detect it

Look for evidence of attempted or successful exploitation in kernel and system logs around HID device attachment, pen/tablet input activity, USB disconnects, driver unbinds, module unloads, and crashes. Relevant sources include journalctl/kernel ring buffer logs, /var/log/kern.log, /var/log/messages, crash dumps, pstore/ramoops records, hypervisor USB pass-through logs, endpoint device-control logs, and EDR telemetry for module load/unload or sysfs driver unbind writes. Indicators include kernel oops or panic entries shortly after a Letsketch/HID tablet device is connected or removed, KASAN or slab-use-after-free reports involving letsketch_inrange_timeout, letsketch_raw_event, input_report_key, input_sync, timer callbacks, or HID teardown paths. Also review administrative or process activity that writes to HID driver unbind files under /sys/bus/hid/drivers/ or unloads HID-related modules near the time of a crash. Because exploitation may only produce a generic kernel crash and there are no known public exploit artifacts, detection should rely on behavioral correlation: suspicious HID device enumeration followed within seconds by disconnect/unbind and kernel memory-safety faults.

• letsketch_inrange_timeout
• letsketch_raw_event
• input_report_key
• input_sync
• use-after-free
• slab-use-after-free
• KASAN: use-after-free
• BUG: KASAN
• kernel BUG
• Oops:
• Kernel panic
• /sys/bus/hid/drivers/letsketch/unbind
• /sys/bus/hid/drivers/*/unbind
• hid-letsketch
• letsketch
• HID: letsketch
• timer_shutdown_sync
• hid_hw_stop

What your security team should do

• Prioritize patching Linux workstations, kiosks, shared-user systems, lab machines, and servers with USB or HID pass-through exposure.
• Inventory systems where the letsketch HID driver is present, loadable, or used, and correlate that inventory with physical-access and peripheral-control risk.
• Apply vendor kernel updates as soon as available; where versions are not yet available, track distribution errata for the backported fix.
• Temporarily block untrusted USB/HID devices using USB allowlisting, endpoint device-control tooling, BIOS/UEFI port controls, hypervisor USB pass-through restrictions, or physical port controls.
• Disable or blacklist the affected driver on systems that do not require Letsketch tablet support, after confirming this will not disrupt business workflows.
• Monitor kernel logs for oops, panic, KASAN, or slab-use-after-free messages referencing the letsketch driver, HID input handling, timer callbacks, or input_report_key/input_sync activity.
• Treat suspicious crashes following USB HID attachment or removal as potential exploitation attempts and preserve kernel logs, crash dumps, and device metadata for investigation.