CRITICAL Introduced in 4.8
ceph CapFlush UAF
CVE-2026-89655
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
KernelScan AI7.0HIGH
01Description
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.
02KernelScan AI Analysis
Risk summary
A use-after-free in the Ceph filesystem client's cap-flushing logic can be triggered by any local user with access to a mounted Ceph filesystem. The race between a cap-flush iteration and an incoming server acknowledgment frees an object the iterator still references, leading to kernel memory corruption that can result in privilege escalation or a system crash. Products that mount Ceph filesystems and expose them to untrusted or multi-tenant local users are most at risk.
Vulnerability analysis
A use-after-free exists in the Ceph filesystem client's cap-flushing logic. When the client iterates pending cap-flush entries to send them to the metadata server, it temporarily releases the inode lock to transmit each message. During that unlock window, a concurrently processed flush acknowledgment from the server can remove and free the very entry the iterator is currently positioned on. When the original thread reacquires the lock and the loop macro advances, it dereferences the freed object's next pointer. The fix saves the next list pointer before dropping the lock and uses that saved pointer after reacquiring it, so the freed entry is never accessed again. This path is reachable by any local user with access to a mounted Ceph filesystem — the mount itself requires root, but ordinary file I/O on the mount triggers cap flushing. The race window depends on how quickly the metadata server responds, so a compromised or malicious server could make exploitation more reliable.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 5.15 | 4.8 | 5.15.221 | 015424300810 |
| 5.10 | 4.8 | 5.10.270 | 091137821e1f |
| 6.6 | 4.8 | 6.6.157 | 19f16f04c2b0 |
| 6.1 | 4.8 | 6.1.188 | 23eb34a53a53 |
| 6.12 | 4.8 | 6.12.109 | 2701431aa3cc |
| 7.2 | 4.8 | 7.2.4 | 2dba24dcd505 |
| mainline | 4.8 | 7.3-rc1 | 7af4c4f01305 |
| 6.18 | 4.8 | 6.18.50 | fe46746087b5 |