CVE-2026-89655

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

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

listforeachentry() iterates ci->icapflushlist but drops

icephlock to send cap messages.  During the unlock window,

handlecapflushack() can acquire iceph_lock, detach cf entries

with tid <= flushtid from the list, release iceph_lock, and free

them via cephfreecap_flush() 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 FLUSH_ACK(tid=10)

                           --->       acquires icephlock

                                      cf->tid(10) <= flush_tid(10),

                                      detaches cf from icapflush_list

                                      drops icephlock

                                      cephfreecap_flush(cf) <- frees it!

  acquires icephlock     <---

  for-loop advances:

    cf = listnextentry(cf, i_list)

      -- UAF on freed cf->i_list.next

The cf was just sent by kickflushingcaps itself via send_cap().

The MDS may respond with FLUSH_ACK quickly enough that

handlecapflushack() frees cf before kickflushing_caps 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.