GHSA-4M75-5382-C595
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-09-04 18:31In the Linux kernel, the following vulnerability has been resolved:
netpoll: fix a use-after-free on shutdown path
There is a use-after-free error on netpoll, which is clearly detected by KASAN.
BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0x3b/0x80
Read of size 1 at addr ... by task kworker/9:1
Workqueue: events queue_process
Call Trace:
skb_dequeue+0x1e/0xb0
queue_process+0x2c/0x600
process_scheduled_works+0x4b6/0x850
worker_thread+0x414/0x5a0
Allocated by task 242:
__netpoll_setup+0x201/0x4a0
netpoll_setup+0x249/0x550
enabled_store+0x32f/0x380
Freed by task 0:
kfree+0x1b7/0x540
rcu_core+0x3f8/0x7a0
The problem happens when there is a pending TX worker running in parallel with the cleanup path.
This is what happens on netpoll shutdown path:
1) __netpoll_cleanup() is called 2) set dev->npinfo to NULL 3) call_rcu() with rcu_cleanup_netpoll_info() 3.1) rcu_cleanup_netpoll_info() tries to cancel all workers with cancel_delayed_work(), but doesn't wait for the worker to finish 4) and kfree(npinfo);
Because 3.1) doesn't really cancel the work, as the comment says "we can't call cancel_delayed_work_sync here, as we are in softirq", the TX worker can run after 4).
Tl;DR: queue_process() is not an RCU reader, it reaches npinfo through the work item via container_of().
Use disable_delayed_work_sync() to ensure the worker is completely stopped and prevent any future re-arming attempts. Once npinfo is set to NULL, senders will bail out and not queue new work. The disable flag ensures any in-flight re-arming attempts also fail silently.
In the future, we can do the cleanup inline here without needing the npinfo->rcu rcu_head, but that is net-next material.
{
"affected": [],
"aliases": [
"CVE-2026-64424"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:26Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetpoll: fix a use-after-free on shutdown path\n\nThere is a use-after-free error on netpoll, which is clearly detected by\nKASAN.\n\n BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0x3b/0x80\n Read of size 1 at addr ... by task kworker/9:1\n Workqueue: events queue_process\n Call Trace:\n skb_dequeue+0x1e/0xb0\n queue_process+0x2c/0x600\n process_scheduled_works+0x4b6/0x850\n worker_thread+0x414/0x5a0\n Allocated by task 242:\n __netpoll_setup+0x201/0x4a0\n netpoll_setup+0x249/0x550\n enabled_store+0x32f/0x380\n Freed by task 0:\n kfree+0x1b7/0x540\n rcu_core+0x3f8/0x7a0\n\nThe problem happens when there is a pending TX worker running in\nparallel with the cleanup path.\n\nThis is what happens on netpoll shutdown path:\n\n1) __netpoll_cleanup() is called\n2) set dev-\u003enpinfo to NULL\n3) call_rcu() with rcu_cleanup_netpoll_info()\n 3.1) rcu_cleanup_netpoll_info() tries to cancel all workers with\n cancel_delayed_work(), but doesn\u0027t wait for the worker to finish\n4) and kfree(npinfo);\n\nBecause 3.1) doesn\u0027t really cancel the work, as the comment says \"we\ncan\u0027t call cancel_delayed_work_sync here, as we are in softirq\", the TX\nworker can run after 4).\n\nTl;DR: queue_process() is not an RCU reader, it reaches npinfo through\nthe work item via container_of().\n\nUse disable_delayed_work_sync() to ensure the worker is completely\nstopped and prevent any future re-arming attempts. Once npinfo is set\nto NULL, senders will bail out and not queue new work. The disable flag\nensures any in-flight re-arming attempts also fail silently.\n\nIn the future, we can do the cleanup inline here without needing the\nnpinfo-\u003ercu rcu_head, but that is net-next material.",
"id": "GHSA-4m75-5382-c595",
"modified": "2026-09-04T18:31:12Z",
"published": "2026-07-25T12:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64424"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/45f1458a85017a023f138b22ac5c76abd477db42"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5ed09a108d93a3b002cc79823d9455b50c4a8be7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/95ecc5b58042f6b6743b589e6588f1cd7ba336aa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a33f37f8d079da7236ed7b7e2aed2a34ab81e7cf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.