CVE-2026-98789: bpf: Fix objects stuck in free_by_rcu_ttrace

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix objects stuck in freebyrcuttrace

docallrcuttrace() returns early when callrcuttraceinprogress is set and leaves the objects in freebyrcuttrace. freercu() frees waitingforgpttrace only and clears the flag. Hence the objects that freebulk() or freebyrcu() added while RCU tasks trace GP was in flight stay in freebyrcuttrace until freebulk() or allocbulk() is called for the same bpfmemcache again, which may never happen. The number of such objects is not bounded.

Turn callrcuttraceinprogress into three states: 0 - idle 1 - freercu() is queued 2 - freercu() is queued and freebyrcuttrace got more objects since

docallrcuttrace() sets 2. freercu() does cmpxchg(1 -> 0) and starts the next GP when it fails. It cannot clear the flag first and check freebyrcuttrace later, since bpfmemallocdestroy() frees bpfmemcache without waiting for RCU callbacks when the flag is zero.

Now freercu() queues itself, so the one that didn't see 'draining' may do callrcutaskstrace() after rcubarriertaskstrace() in freememalloc(). Queue it under rcureadlock() and do synchronizercu() before the barriers. Calling rcubarriertaskstrace() twice works too, but creating and destroying hash maps in a loop on many cpus slows down to one freememalloc() per GP and kworkers pile up.