GHSA-9437-XJ9F-2C6G
Vulnerability from github – Published: 2026-10-18 18:31 – Updated: 2026-10-18 18:31In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix UAF due to concurrent consumption of ttrace lists in alloc_bulk
Syzkaller repeatedly triggered UAF splats related to nodes in waiting_for_gp_ttrace within the bpf memalloc:
BUG: KASAN: slab-use-after-free in llist_del_first+0x85/0x110 lib/llist.c:61 Read of size 8 at addr ffff8881572cd080 by task syz.4.470/5112 ... llist_del_first+0x85/0x110 lib/llist.c:61 alloc_bulk+0x193/0x460 kernel/bpf/memalloc.c:229 bpf_mem_refill+0x386/0x560 kernel/bpf/memalloc.c:436
Freed by task 14: ... __free_rcu kernel/bpf/memalloc.c:281 [inline] __free_rcu_tasks_trace+0x48/0xd0 kernel/bpf/memalloc.c:291 rcu_tasks_invoke_cbs+0x1ec/0x3e0 kernel/rcu/tasks.h:571 rcu_tasks_one_gp+0x13d/0x220 kernel/rcu/tasks.h:621 rcu_tasks_kthread+0xf3/0x120 kernel/rcu/tasks.h:651
The reason is that the UAF occurs after the RCU Tasks Trace GP expires: when the __free_rcu() callback runs, there is no synchronization protecting llist_del_all() against concurrent alloc_bulk() operating on waiting_for_gp_ttrace, leading to the race condition below:
CPU0 CPU1 __free_rcu (RCU Tasks Trace callback) alloc_bulk llist_del_first(&c->waiting_for_gp_ttrace) entry = smp_load_acquire(&head->first); do { if (entry == NULL) return NULL; free_all(llist_del_all(&c->waiting_for_gp_ttrace)) llist_for_each_safe(pos, t, llnode) free_one(pos); next = READ_ONCE(entry->next); <-- trigger UAF } while (!try_cmpxchg(&head->first, &entry, next));
In addition, there is also a theoretical race condition on the free_by_rcu_ttrace list. This race requires two preconditions: an in-flight Tasks Trace GP keeping c->call_rcu_ttrace_in_progress == 1, and concurrent cross-CPU frees repopulating c->free_by_rcu_ttrace with new nodes. Under these conditions, the following scenario triggers UAF:
// CPU0 // irq work is still busy (on PREEMPT_RT) alloc_bulk() llist_del_first(&c->free_by_rcu_ttrace) entry = smp_load_acquire(&head->first); do { if (entry == NULL) return NULL;
// CPU1
bpf_mem_alloc_destroy()
WRITE_ONCE(c->draining, true)
// wait for CPU0
irq_work_sync()
// CPU2
do_call_rcu_ttrace(tgt(CPU0))
if (c->draining) {
llist_del_all(&c->free_by_rcu_ttrace)
free_all()
}
// CPU0 continue next = READ_ONCE(entry->next); <-- trigger UAF while (!try_cmpxchg(&head->first, &entry, next));
Fix this by introducing a raw spinlock to synchronize the concurrent consumption on waiting_for_gp_ttrace and free_by_rcu_ttrace.
{
"affected": [],
"aliases": [
"CVE-2026-98642"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-18T16:17:17Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix UAF due to concurrent consumption of ttrace lists in alloc_bulk\n\nSyzkaller repeatedly triggered UAF splats related to nodes in\nwaiting_for_gp_ttrace within the bpf memalloc:\n\nBUG: KASAN: slab-use-after-free in llist_del_first+0x85/0x110 lib/llist.c:61\nRead of size 8 at addr ffff8881572cd080 by task syz.4.470/5112\n ...\n llist_del_first+0x85/0x110 lib/llist.c:61\n alloc_bulk+0x193/0x460 kernel/bpf/memalloc.c:229\n bpf_mem_refill+0x386/0x560 kernel/bpf/memalloc.c:436\n\nFreed by task 14:\n ...\n __free_rcu kernel/bpf/memalloc.c:281 [inline]\n __free_rcu_tasks_trace+0x48/0xd0 kernel/bpf/memalloc.c:291\n rcu_tasks_invoke_cbs+0x1ec/0x3e0 kernel/rcu/tasks.h:571\n rcu_tasks_one_gp+0x13d/0x220 kernel/rcu/tasks.h:621\n rcu_tasks_kthread+0xf3/0x120 kernel/rcu/tasks.h:651\n\nThe reason is that the UAF occurs after the RCU Tasks Trace GP expires:\nwhen the __free_rcu() callback runs, there is no synchronization\nprotecting llist_del_all() against concurrent alloc_bulk() operating on\nwaiting_for_gp_ttrace, leading to the race condition below:\n\nCPU0 CPU1\n __free_rcu (RCU Tasks Trace callback)\nalloc_bulk\n llist_del_first(\u0026c-\u003ewaiting_for_gp_ttrace)\n entry = smp_load_acquire(\u0026head-\u003efirst);\n do {\n if (entry == NULL)\n return NULL;\n free_all(llist_del_all(\u0026c-\u003ewaiting_for_gp_ttrace))\n llist_for_each_safe(pos, t, llnode)\n free_one(pos);\n next = READ_ONCE(entry-\u003enext); \u003c-- trigger UAF\n } while (!try_cmpxchg(\u0026head-\u003efirst, \u0026entry, next));\n\nIn addition, there is also a theoretical race condition on the\nfree_by_rcu_ttrace list. This race requires two preconditions: an\nin-flight Tasks Trace GP keeping c-\u003ecall_rcu_ttrace_in_progress == 1,\nand concurrent cross-CPU frees repopulating c-\u003efree_by_rcu_ttrace with\nnew nodes. Under these conditions, the following scenario triggers UAF:\n\n// CPU0\n// irq work is still busy (on PREEMPT_RT)\nalloc_bulk()\n llist_del_first(\u0026c-\u003efree_by_rcu_ttrace)\n entry = smp_load_acquire(\u0026head-\u003efirst);\n do {\n if (entry == NULL)\n return NULL;\n\n // CPU1\n bpf_mem_alloc_destroy()\n WRITE_ONCE(c-\u003edraining, true)\n // wait for CPU0\n irq_work_sync()\n\n // CPU2\n do_call_rcu_ttrace(tgt(CPU0))\n if (c-\u003edraining) {\n llist_del_all(\u0026c-\u003efree_by_rcu_ttrace)\n free_all()\n }\n\n// CPU0 continue\n next = READ_ONCE(entry-\u003enext); \u003c-- trigger UAF\n while (!try_cmpxchg(\u0026head-\u003efirst, \u0026entry, next));\n\nFix this by introducing a raw spinlock to synchronize the concurrent\nconsumption on waiting_for_gp_ttrace and free_by_rcu_ttrace.",
"id": "GHSA-9437-xj9f-2c6g",
"modified": "2026-10-18T18:31:57Z",
"published": "2026-10-18T18:31:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98642"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1c21452d02eec2f008e2c5535820f85adbd7587a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1d6581b544a88cf4348c2fb60dcb50ad63f012da"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a0e150a118025a05c8662c536ba2a865da86419c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f101602415fb39a58941bec444df65634d5a6844"
}
],
"schema_version": "1.4.0",
"severity": []
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
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.