Live › vulnerability › CVE-2026-98789
Go to dashboardThe BPF memory allocator can leave freed objects stuck in a pending list when an RCU tasks trace grace period is in flight, because the free path returns early and never drains them. The sources describe a resource leak with unbounded growth, not a code execution or data disclosure path.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with the BPF memory allocator that create and destroy BPF maps repeatedly, such as tracing or networking tooling on busy multi-CPU hosts. Hosts that do not load BPF programs or maps dynamically can likely skip it, but the sources do not say which kernel versions are affected.
No product ranges from the sources yet.
uname -r and compare against the fixed kernel stable release listed in the NVD entry for CVE-2026-98789Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix objects stuck in free_by_rcu_ttrace
do_call_rcu_ttrace() returns early when call_rcu_ttrace_in_progress is set and leaves the objects in free_by_rcu_ttrace. __free_rcu() frees waiting_for_gp_ttrace only and clears the flag. Hence the objects that free_bulk() or __free_by_rcu() added while RCU tasks trace GP was in flight stay in free_by_rcu_ttrace until free_bulk() or alloc_bulk() is called for the same bpf_mem_cache again, which may never happen. The number of such objects is not bounded.
Turn call_rcu_ttrace_in_progress into three states: 0 - idle 1 - __free_rcu() is queued 2 - __free_rcu() is queued and free_by_rcu_ttrace got more objects since
do_call_rcu_ttrace() sets 2. __free_rcu() does cmpxchg(1 -> 0) and starts the next GP when it fails. It cannot clear the flag first and check free_by_rcu_ttrace later, since bpf_mem_alloc_destroy() frees bpf_mem_cache without waiting for RCU callbacks when the flag is zero.
Now __free_rcu() queues itself, so the one that didn't see 'draining' may do call_rcu_tasks_trace() after rcu_barrier_tasks_trace() in free_mem_alloc(). Queue it under rcu_read_lock() and do synchronize_rcu() before the barriers. Calling rcu_barrier_tasks_trace() twice works too, but creating and destroying hash maps in a loop on many cpus slows down to one free_mem_alloc() per GP and kworkers pile up.
This page as .md · .json · in your agent: get_signal("CVE-2026-98789")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.