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.