CVE-2026-80766
CVE CVE-2026-80766EUVD EUVD-2026-71409Published 2026-09-04T15:12:38.000Z
What the advisory describes
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.
Source: EUVD (ENISA), in the words of the advisory.
Products the advisory names
These come from the advisory itself, not from any check we performed.
- Linux — Linux 01309e29eb95c16bd48984f2589fad0cbf5e27d1 <f1b3ca06380531f49f988f4721d3ed30b0d7a5d2; patch: 6.18.47; patch: 5.15.220; patch: 0; patch: 6.1.187; patch: 7.1.11; patch: 6.6.156; 01309e29eb95c16bd48984f2589fad0cbf5e27d1 <f40243358b407aec362fe305fabfcdc94a3abd89; 01309e29eb95c16bd48984f2589fad0cbf5e27d1 <849e537160bbb77fe419ecc3944bfe125dcd441b; 01309e29eb95c16bd48984f2589fad0cbf5e27d1 <e750cdb6de009aace3c77f37fe2173f96175e8e4; patch: 7.2.1; 01309e29eb95c16bd48984f2589fad0cbf5e27d1 <9d77ac82e57ead056cf3f71d347083ed9244ad90; patch: 7.3-rc1; 5.1; patch: 6.12.108; 01309e29eb95c16bd48984f2589fad0cbf5e27d1 <dc5108f18f58870a8dd4203a02a47e571a2be7f0; 01309e29eb95c16bd48984f2589fad0cbf5e27d1 <506fd50a9027340f0e9dcc587d10ccb03312dba6; 01309e29eb95c16bd48984f2589fad0cbf5e27d1 <f13d0a00204b05e62336da0ab72ea0d87b56690c
The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.
Carried in the product catalogue
An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.
- Linux — Linux
Does this concern one of your customers?
This page cannot answer that — it does not know your estate. Whoever has recorded their environments gets the answer the morning after publication, together with a paragraph they can forward to the customer unedited.
Try it for 28 daysPatchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.