Cloudanix VulnDB

CVE-2026-80766

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in how the Linux kernel cleans up certain drawing tablet drivers can let a specially timed unplug or removal corrupt memory and potentially crash the system or run attacker code.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in timer-softirq context: uclogic_remove() cancels inrange_timer then calls hid_hw_stop(), but a pending pen report can re-arm the timer via mod_timer() between those calls; after drvdata and pen_input are freed the timer callback dereferences the freed objects.

Why it matters to the business

Local privilege escalation or kernel crash on systems using uclogic-based drawing tablets or similar HID devices; requires physical device or crafted input and is not remotely exploitable without additional vectors.

How an attack unfolds

An attacker with the ability to trigger pen reports (via attached hardware or emulated device) during driver unload causes a freed timer to fire and execute attacker-controlled or NULL dereference code in softirq context, leading to memory corruption.

How to fix it

Upgrade to a kernel containing the fix that replaces timer_delete_sync() with timer_shutdown_sync() before hid_hw_stop(). Apply the stable backport for the affected kernel branch; no configuration workaround exists.

How to confirm the fix worked

Confirm the presence of timer_shutdown_sync() call in uclogic_remove() and absence of the original timer_delete_sync + hid_hw_stop ordering; run kernel build with CONFIG_HID_UCLOGIC=y and verify module loads without warnings on device attach/detach.

Typical attack path

  1. Attach or emulate uclogic HID pen device that generates inrange reports
  2. Trigger module or device removal (rmmod, unplug, or system suspend/resume path)
  3. Race window allows mod_timer after timer_delete_sync but before hid_hw_stop completes
  4. Timer fires on freed drvdata/pen_input, causing use-after-free in softirq

How to detect it

Inspect kernel logs for uclogic-related oops or use-after-free warnings during device removal; look for timer callbacks referencing freed HID input objects in crash dumps or KASAN reports.

What your security team should do

  • Prioritize kernel update on any system exposing uclogic HID devices to untrusted input
  • Monitor for future stable releases that include this timer-teardown ordering fix
  • Restrict physical access to drawing tablets on multi-user or kiosk systems until patched

The record

In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: fix use-after-free of inrange_timer on remove uclogic_remove() cancels the pen in-range timer and then stops the device: timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev); timer_delete_sync() only guarantees the timer is idle at that instant. uclogic_raw_event_pen() keeps delivering pen reports until hid_hw_stop() stops the transport several lines later, and every report with pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE re-arms the timer: mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); A report landing between the timer_delete_sync() call and the transport teardown in hid_hw_stop() re-arms inrange_timer after it was cancelled. uclogic_remove() then returns and the devm drvdata is freed, while hid_hw_stop() has already freed the input device drvdata->pen_input points at, so when the timer fires ~100 ms later uclogic_inrange_timeout() dereferences freed memory -- a use-after-free in timer-softirq context. Swapping the two calls is not a fix: stopping the device first frees drvdata->pen_input via hidinput_disconnect() while the timer may still be pending, so a timer already armed before removal fires on the freed input device in the window before timer_delete_sync() runs. Use timer_shutdown_sync() before hid_hw_stop() instead. It cancels the timer, waits for a running callback while pen_input is still valid, and prevents any further re-arming -- a later mod_timer() from an in-flight report is silently ignored -- so the timer is provably dead before hid_hw_stop() frees the inputs. This is the ordering the timer core documents for this "timer re-armed from another path" teardown case.

Affected packages

Ecosystem Package Introduced Fixed