Cloudanix VulnDB

CVE-2026-98642

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A race condition in the Linux kernel's BPF memory handling could let an attacker cause crashes or instability on affected systems.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in the BPF memory allocator caused by unsynchronized concurrent access to waiting_for_gp_ttrace and free_by_rcu_ttrace RCU Tasks Trace lists between alloc_bulk and RCU callback freeing paths.

Why it matters to the business

Kernel instability or crashes on systems running BPF workloads under load or with concurrent memory operations, potentially leading to denial of service; low immediate exploit risk given current scores and no known campaigns.

How an attack unfolds

An attacker triggers repeated allocation and freeing patterns in BPF memalloc (via crafted programs or fuzzing) to race llist_del_first against llist_del_all in the RCU Tasks Trace callback, reading a freed next pointer after the grace period expires.

How to fix it

Apply the upstream fix that adds a raw spinlock to protect consumption of both ttrace lists in alloc_bulk and related paths; rebuild and deploy the patched kernel across all affected systems.

How to confirm the fix worked

Confirm the spinlock is present around llist operations on waiting_for_gp_ttrace and free_by_rcu_ttrace in kernel/bpf/memalloc.c; re-run the original syzkaller reproducer or stress tests to verify absence of KASAN UAF reports.

Typical attack path

  1. Load or attach BPF programs that exercise memalloc paths under contention
  2. Trigger RCU Tasks Trace grace periods while allocations are in flight on waiting_for_gp_ttrace
  3. Cause concurrent __free_rcu callback execution and llist operations
  4. Read freed list node next pointer leading to slab UAF

How to detect it

Search kernel logs for KASAN slab-use-after-free splats referencing llist_del_first, alloc_bulk, bpf_mem_refill, or __free_rcu in memalloc.c; inspect for repeated UAF patterns during high BPF allocation activity.

  • BUG: KASAN: slab-use-after-free in llist_del_first
  • alloc_bulk+0x193/0x460 kernel/bpf/memalloc.c:229
  • bpf_mem_refill+0x386/0x560 kernel/bpf/memalloc.c:436
  • __free_rcu kernel/bpf/memalloc.c:281

What your security team should do

  • Patch kernels to the version containing the spinlock fix as soon as available
  • Monitor for KASAN or slab UAF reports in BPF workloads
  • Limit unprivileged BPF access until patched

The record

In 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 packages

Ecosystem Package Introduced Fixed