Linux CephFS client: use-after-free when a cap-flush entry is freed by a fast FLUSH_ACK mid-iteration

UnscoredCVE-2026-89655Kernel, userspace & hypervisorcurated

Impact

__kick_flushing_caps() iterates ci->i_cap_flush_list with list_for_each_entry() but drops i_ceph_lock to send each cap message. If the MDS answers with FLUSH_ACK quickly enough, handle_cap_flush_ack() detaches the entry and frees it outside any lock; the loop macro then dereferences cf->i_list.next on freed memory. The window is opened by the client's own send, so it needs no attacker - a responsive MDS under load is enough. On a GPU node with a kernel CephFS mount this is an unplanned node crash during normal filesystem writeback, which is exactly the kind of failure that costs a long-running training job. The fix converts the loop to save the next pointer under i_ceph_lock before dropping it.

Who can reach it

No authentication or tenant access needed to trigger - it is a timing race between the client's cap flush and the MDS ack. An attacker controlling the MDS could make fast acks more likely, but ordinary cluster latency suffices.

What to do

Update to a stable kernel carrying the fix (four backport commits linked on the record); drain and reboot each node holding a kernel CephFS mount, since the client cannot be reloaded under a live mount. Batch with the other ceph fixes from the same day. No configuration change avoids it.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-89655 https://git.kernel.org/stable/c/2701431aa3cc8b23efe6890182e7b04f5e76fab5 https://git.kernel.org/stable/c/2dba24dcd5050be4b7b119e6f0b01f62203b5d26 https://git.kernel.org/stable/c/7af4c4f01305b0935adf6d4301b1ec407025485d

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.