CVE-2026-98789: bpf: Fix objects stuck in free_by_rcu_ttrace
bpf: Fix objects stuck in freebyrcuttrace
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Update the Linux kernel BPF memory allocator RCU task-trace handling: represent call_rcu_ttrace_in_progress with states 0 (idle), 1 (__free_rcu() queued), and 2 (__free_rcu() queued with additional objects in free_by_rcu_ttrace); have do_call_rcu_ttrace() set state 2, and have __free_rcu() perform cmpxchg(1 -> 0) and start the next grace period when the exchange fails.
- Compensating control
Queue __free_rcu() under rcu_read_lock() and call synchronize_rcu() before the rcu_barrier_tasks_trace() barriers so callbacks added during the RCU tasks-trace grace period are not left in free_by_rcu_ttrace.
Event History
Frequently Asked Questions
Which systems are exposed to the stuck-object condition?
The condition applies to BPF memory caches when free_bulk() or __free_by_rcu() adds objects while an RCU tasks-trace grace period is already in flight. The provided information does not identify any particular default configuration or attacker prerequisite.
What is the operational impact if the condition occurs?
Objects can remain in free_by_rcu_ttrace instead of being freed, and their number is not bounded. They may remain there indefinitely if the same bpf_mem_cache is never used again by free_bulk() or alloc_bulk().
Why can cache destruction be affected by this race?
bpf_mem_alloc_destroy() can free a bpf_mem_cache without waiting for RCU callbacks when the progress flag is zero. The fix changes the progress tracking and requeues __free_rcu() so newly added objects are handled before that state is cleared.