CVE-2026-80766

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);

timerdeletesync() only guarantees the timer is idle at that instant. uclogicraweventpen() keeps delivering pen reports until hidhwstop() stops the transport several lines later, and every report with pen->inrange == UCLOGICPARAMSPENINRANGE_NONE re-arms the timer:

mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100));

A report landing between the timerdeletesync() call and the transport teardown in hidhwstop() re-arms inrangetimer after it was cancelled. uclogicremove() then returns and the devm drvdata is freed, while hidhwstop() has already freed the input device drvdata->peninput points at, so when the timer fires ~100 ms later uclogicinrange_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->peninput via hidinputdisconnect() while the timer may still be pending, so a timer already armed before removal fires on the freed input device in the window before timerdeletesync() runs.

Use timershutdownsync() before hidhwstop() instead. It cancels the timer, waits for a running callback while peninput is still valid, and prevents any further re-arming -- a later modtimer() from an in-flight report is silently ignored -- so the timer is provably dead before hidhwstop() frees the inputs. This is the ordering the timer core documents for this "timer re-armed from another path" teardown case.