CVE-2026-89655ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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.
- CVSS
- 9.8 CRITICAL (v3.1, CNA)CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Oct 16, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from e4500b5e35c213e0f97be7cb69328c0877203a79 before 091137821e1fc88f37e15201abf055c9494ddc61; from e4500b5e35c213e0f97be7cb69328c0877203a79 before 01542430081014d80fc9e70e92d6647432ddb7fc; from e4500b5e35c213e0f97be7cb69328c0877203a79 before 23eb34a53a53cb1a6dab1eeee830633207ac158d; from e4500b5e35c213e0f97be7cb69328c0877203a79 before 19f16f04c2b014a7dd214dc1e42557d8530b16f3; from e4500b5e35c213e0f97be7cb69328c0877203a79 before 2701431aa3cc8b23efe6890182e7b04f5e76fab5; from e4500b5e35c213e0f97be7cb69328c0877203a79 before fe46746087b5b9c5bb2d022df6c7819218494ced; from e4500b5e35c213e0f97be7cb69328c0877203a79 before 2dba24dcd5050be4b7b119e6f0b01f62203b5d26; from e4500b5e35c213e0f97be7cb69328c0877203a79 before 7af4c4f01305b0935adf6d4301b1ec407025485d | CNA record |
References
- https://git.kernel.org/stable/c/091137821e1fc88f37e15201abf055c9494ddc61
- https://git.kernel.org/stable/c/01542430081014d80fc9e70e92d6647432ddb7fc
- https://git.kernel.org/stable/c/23eb34a53a53cb1a6dab1eeee830633207ac158d
- https://git.kernel.org/stable/c/19f16f04c2b014a7dd214dc1e42557d8530b16f3
- 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
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.