DEBIAN-CVE-2026-89655

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 iceph_lock before dropping it, then use the saved pointer after reacquiring, so the potentially-freed cf is never accessed again.