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

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

[Greg Kroah-Hartman]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

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

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

list_for_each_entry() iterates ci->i_cap_flush_list but drops
i_ceph_lock to send cap messages.  During the unlock window,
handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries
with tid <= flush_tid from the list, release i_ceph_lock, and free
them via ceph_free_cap_flush() outside any lock.  When the original
thread reacquires i_ceph_lock and the for-loop macro advances via
cf = list_next_entry(cf, i_list), it dereferences cf->i_list.next
on freed memory.

The race timeline:

  __kick_flushing_caps()              handle_cap_flush_ack()
  -----------------------             -----------------------
  holds i_ceph_lock        <---
  iterates to cf (tid=10)
  prepares FLUSH message
  drops i_ceph_lock        <---
  __send_cap() ── FLUSH(tid=10)
	                              MDS sends FLUSH_ACK(tid=10)
                           --->       acquires i_ceph_lock
                                      cf->tid(10) <= flush_tid(10),
                                      detaches cf from i_cap_flush_list
                                      drops i_ceph_lock
                                      ceph_free_cap_flush(cf) <- frees it!
  acquires i_ceph_lock     <---
  for-loop advances:
    cf = list_next_entry(cf, i_list)
      -- UAF on freed cf->i_list.next

The cf was just sent by __kick_flushing_caps itself via __send_cap().
The MDS may respond with FLUSH_ACK quickly enough that
handle_cap_flush_ack() frees cf before __kick_flushing_caps can
finish the iteration.

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

The Linux kernel CVE team has assigned CVE-2026-89655 to this issue.


Affected and fixed versions
===========================

	Fixed in 6.12.109 with commit 2701431aa3cc8b23efe6890182e7b04f5e76fab5
	Fixed in 6.18.50 with commit fe46746087b5b9c5bb2d022df6c7819218494ced
	Fixed in 7.2.4 with commit 2dba24dcd5050be4b7b119e6f0b01f62203b5d26
	Fixed in 7.3-rc1 with commit 7af4c4f01305b0935adf6d4301b1ec407025485d

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-89655
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/ceph/caps.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/2701431aa3cc8b23efe6890182e7b04f5e76fab5
	https://git.kernel.org/stable/c/fe46746087b5b9c5bb2d022df6c7819218494ced
	https://git.kernel.org/stable/c/2dba24dcd5050be4b7b119e6f0b01f62203b5d26
	https://git.kernel.org/stable/c/7af4c4f01305b0935adf6d4301b1ec407025485d