CVE-2026-89655: ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock

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

ceph: fix UAF in kickflushingcaps() on cf entry freed during unlock

listforeachentry() iterates ci->icapflushlist but drops icephlock to send cap messages. During the unlock window, handlecapflushack() can acquire icephlock, detach cf entries with tid <= flushtid from the list, release icephlock, and free them via cephfreecapflush() outside any lock. When the original thread reacquires icephlock and the for-loop macro advances via cf = listnextentry(cf, ilist), it dereferences cf->ilist.next on freed memory.

The race timeline:

kickflushingcaps() handlecapflushack() ----------------------- ----------------------- holds icephlock <--- iterates to cf (tid=10) prepares FLUSH message drops icephlock <--- sendcap() ── FLUSH(tid=10) MDS sends FLUSHACK(tid=10) ---> acquires icephlock cf->tid(10) <= flushtid(10), detaches cf from icapflushlist drops icephlock cephfreecapflush(cf) <- frees it! acquires icephlock <--- for-loop advances: cf = listnextentry(cf, ilist) -- UAF on freed cf->ilist.next

The cf was just sent by kickflushingcaps itself via sendcap(). The MDS may respond with FLUSHACK quickly enough that handlecapflushack() frees cf before kickflushingcaps can finish the iteration.

Fix by converting to a manual while loop: save the next pointer under icephlock before dropping it, then use the saved pointer after reacquiring, so the potentially-freed cf is never accessed again.