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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:51.683Z",
  "pubdate": "2026-09-11T20:19:51.683Z",
  "executiveSummary": "A Use-After-Free (UAF) vulnerability exists in the Linux kernel's Ceph file system implementation within the __kick_flushing_caps function.\nThe vulnerability arises from an unsafe iteration pattern over the i_cap_flush_list while dropping and reacquiring the i_ceph_lock, allowing race conditions with concurrent cap flush acknowledgments.\nAn attacker capable of triggering specific cap flush operations could potentially cause a kernel panic, memory corruption, or local privilege escalation.\nThe flaw affects Linux kernel systems utilizing the Ceph file system client.\nExploitation requires the victim to trigger high-frequency cap flush operations that allow a race condition between the flush processing thread and the acknowledgment handling thread.\nThe impact is significant, as kernel-level memory corruption typically results in immediate system instability or potential code execution if the freed memory is reallocated by the slab allocator.",
  "technicalDetails": "The root cause of this vulnerability is a race condition in the __kick_flushing_caps function while iterating through the ci->i_cap_flush_list. In the original implementation, the code utilizes a standard list_for_each_entry() macro to traverse the flushing cap entries. This macro inherently dereferences the current element to fetch the next pointer in the list.\nHowever, __kick_flushing_caps periodically drops the i_ceph_lock to execute __send_cap(), which involves network I/O to the Metadata Server (MDS). During this unprotected window, the handle_cap_flush_ack() function can be triggered by an incoming FLUSH_ACK message from the MDS.\nThe handle_cap_flush_ack() function acquires the i_ceph_lock, identifies that the flush operation with a specific transaction ID (tid) has been acknowledged, removes the cf (cap flush) entry from the i_cap_flush_list, and proceeds to invoke ceph_free_cap_flush(cf) to release the memory.\nWhen the __kick_flushing_caps thread eventually reacquires the i_ceph_lock and attempts to advance the loop, it invokes list_next_entry(cf, i_list), which dereferences cf->i_list.next. Since the cf structure has already been freed by handle_cap_flush_ack(), the process triggers a Use-After-Free condition, resulting in a kernel panic or unpredictable memory corruption.\nThe attack flow requires a synchronization race where the MDS provides an acknowledgment for a cap flush exactly while the client kernel thread is suspended at the point of dropping the i_ceph_lock. By flooding the client with cap flush acknowledgments corresponding to pending requests, an attacker increases the probability of hitting the race window.\nBecause the vulnerability occurs within the kernel's memory management of Ceph-specific data structures, there are no specific authentication requirements beyond being able to influence Ceph file system metadata operations. The impact is elevated to kernel-level execution, as the kernel will attempt to dereference a pointer to memory that may have been repurposed for other kernel objects by the SLAB/SLUB allocator."
}