GHSA-XC7G-5F4M-53H6
Vulnerability from github – Published: 2026-09-04 18:31 – Updated: 2026-09-04 18:31In 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": [],
"aliases": [
"CVE-2026-80766"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-04T16:18:01Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: uclogic: fix use-after-free of inrange_timer on remove\n\nuclogic_remove() cancels the pen in-range timer and then stops the\ndevice:\n\n\ttimer_delete_sync(\u0026drvdata-\u003einrange_timer);\n\thid_hw_stop(hdev);\n\ntimer_delete_sync() only guarantees the timer is idle at that instant.\nuclogic_raw_event_pen() keeps delivering pen reports until hid_hw_stop()\nstops the transport several lines later, and every report with\npen-\u003einrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE re-arms the timer:\n\n\tmod_timer(\u0026drvdata-\u003einrange_timer, jiffies + msecs_to_jiffies(100));\n\nA report landing between the timer_delete_sync() call and the transport\nteardown in hid_hw_stop() re-arms inrange_timer after it was cancelled.\nuclogic_remove() then returns and the devm drvdata is freed, while\nhid_hw_stop() has already freed the input device drvdata-\u003epen_input\npoints at, so when the timer fires ~100 ms later\nuclogic_inrange_timeout() dereferences freed memory -- a use-after-free\nin timer-softirq context.\n\nSwapping the two calls is not a fix: stopping the device first frees\ndrvdata-\u003epen_input via hidinput_disconnect() while the timer may still\nbe pending, so a timer already armed before removal fires on the freed\ninput device in the window before timer_delete_sync() runs.\n\nUse timer_shutdown_sync() before hid_hw_stop() instead. It cancels the\ntimer, waits for a running callback while pen_input is still valid, and\nprevents any further re-arming -- a later mod_timer() from an in-flight\nreport is silently ignored -- so the timer is provably dead before\nhid_hw_stop() frees the inputs. This is the ordering the timer core\ndocuments for this \"timer re-armed from another path\" teardown case.",
"id": "GHSA-xc7g-5f4m-53h6",
"modified": "2026-09-04T18:31:24Z",
"published": "2026-09-04T18:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80766"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/506fd50a9027340f0e9dcc587d10ccb03312dba6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/849e537160bbb77fe419ecc3944bfe125dcd441b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d77ac82e57ead056cf3f71d347083ed9244ad90"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dc5108f18f58870a8dd4203a02a47e571a2be7f0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e750cdb6de009aace3c77f37fe2173f96175e8e4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f13d0a00204b05e62336da0ab72ea0d87b56690c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f1b3ca06380531f49f988f4721d3ed30b0d7a5d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f40243358b407aec362fe305fabfcdc94a3abd89"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.