CVE-2026-98789

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.