Answer in brief
CVE-2026-89655 records a Critical severity (CVSS 9.8) vulnerability in ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 9.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <2701431aa3cc8b23efe6890182e7b04f5e76fab5 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <fe46746087b5b9c5bb2d022df6c7819218494ced || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <2dba24dcd5050be4b7b119e6f0b01f62203b5d26 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <7af4c4f01305b0935adf6d4301b1ec407025485d || >=0 <6.12.109 || >=0 <6.18.50 || >=0 <7.2.4 | 2701431aa3cc8b23efe6890182e7b04f5e76fab5, fe46746087b5b9c5bb2d022df6c7819218494ced, 2dba24dcd5050be4b7b119e6f0b01f62203b5d26, 7af4c4f01305b0935adf6d4301b1ec407025485d, 6.12.109, 6.18.50, 7.2.4 |
| Linux/Linuxgeneric | >=e4500b5e35c213e0f97be7cb69328c0877203a79 <2701431aa3cc8b23efe6890182e7b04f5e76fab5 || >=e4500b5e35c213e0f97be7cb69328c0877203a79 <fe46746087b5b9c5bb2d022df6c7819218494ced || >=e4500b5e35c213e0f97be7cb69328c0877203a79 <2dba24dcd5050be4b7b119e6f0b01f62203b5d26 || >=e4500b5e35c213e0f97be7cb69328c0877203a79 <7af4c4f01305b0935adf6d4301b1ec407025485d | 2701431aa3cc8b23efe6890182e7b04f5e76fab5, fe46746087b5b9c5bb2d022df6c7819218494ced, 2dba24dcd5050be4b7b119e6f0b01f62203b5d26, 7af4c4f01305b0935adf6d4301b1ec407025485d |
| Linux/Linuxgeneric | >=e4500b5e35c213e0f97be7cb69328c0877203a79 <091137821e1fc88f37e15201abf055c9494ddc61 || >=e4500b5e35c213e0f97be7cb69328c0877203a79 <01542430081014d80fc9e70e92d6647432ddb7fc || >=e4500b5e35c213e0f97be7cb69328c0877203a79 <23eb34a53a53cb1a6dab1eeee830633207ac158d || >=e4500b5e35c213e0f97be7cb69328c0877203a79 <19f16f04c2b014a7dd214dc1e42557d8530b16f3 || >=e4500b5e35c213e0f97be7cb69328c0877203a79 <2701431aa3cc8b23efe6890182e7b04f5e76fab5 || >=e4500b5e35c213e0f97be7cb69328c0877203a79 <fe46746087b5b9c5bb2d022df6c7819218494ced || >=e4500b5e35c213e0f97be7cb69328c0877203a79 <2dba24dcd5050be4b7b119e6f0b01f62203b5d26 || >=e4500b5e35c213e0f97be7cb69328c0877203a79 <7af4c4f01305b0935adf6d4301b1ec407025485d | 091137821e1fc88f37e15201abf055c9494ddc61, 01542430081014d80fc9e70e92d6647432ddb7fc, 23eb34a53a53cb1a6dab1eeee830633207ac158d, 19f16f04c2b014a7dd214dc1e42557d8530b16f3, 2701431aa3cc8b23efe6890182e7b04f5e76fab5, fe46746087b5b9c5bb2d022df6c7819218494ced, 2dba24dcd5050be4b7b119e6f0b01f62203b5d26, 7af4c4f01305b0935adf6d4301b1ec407025485d |
| Linux/Linuxgeneric | 4.8 | Not reported |
Published upstream
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 11, 2026
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.
Quoted source text, attributed separately from HOL analysis.