CVE-2026-80766
HID: uclogic: fix use-after-free of inrange_timer on remove
Published Sep 4, 2026
CVSS n/a
EPSS < 1%
KEV · Not listed
Description
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.
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 Products
-
CVE record
-
NVD configurations
No data
-
Red Hat packages
No data
-
OpenCVE enrichment
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux | unaffected |
|
|||||||||||||||||||||||||||||||||
| Linux | Linux | affected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux Kernel |
|
||||||||||||||||||||||||||||||||||||||||||||
| Linux | Linux Kernel |
|
Remediation
Tracking
Advisories
| Source | ID | Title |
|---|---|---|
 Debian DLA |
DLA-4777-1 | linux security update |
| Debian DLA |
DLA-4817-1 | linux-6.12 security update |
 Debian DSA |
DSA-6528-1 | linux security update |
 Ubuntu USN |
USN-8961-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9019-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-9020-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9022-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9023-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9024-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9025-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9026-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-9029-1 | Linux kernel (Raspberry Pi) vulnerabilities |
| Ubuntu USN |
USN-9039-1 | Linux kernel (Azure CVM) vulnerabilities |
| Ubuntu USN |
USN-9040-1 | Linux kernel (Low Latency NVIDIA) vulnerabilities |
| Ubuntu USN |
USN-9066-1 | Linux kernel (HWE) vulnerabilities |
| Ubuntu USN |
USN-9091-1 | Linux kernel (NVIDIA Tegra) vulnerabilities |
Metrics
No CVSS v4.0
No CVSS v3.1
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.177% probability within 30 days)
Key SSVC decision points have not yet been added.
References
History
Sep 4, 2026 5:45 PM
Weaknesses updated
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-416 |
Sep 4, 2026 3:30 PM
Description updated. Title updated. First appearance in the feed. Affected versions updated. Affected vendors updated. Added references
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | HID: uclogic: fix use-after-free of inrange_timer on remove | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
|
Subscriptions
Weaknesses
