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

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.