{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003ei_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 \u003c= 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-\u003ei_list.next on freed memory.  The race timeline:    __kick_flushing_caps()              handle_cap_flush_ack()   -----------------------             -----------------------   holds i_ceph_lock        \u003c---   iterates to cf (tid=10)   prepares FLUSH message   drops i_ceph_lock        \u003c---   __send_cap() ── FLUSH(tid=10) \t                              MDS sends FLUSH_ACK(tid=10)                            ---\u003e       acquires i_ceph_lock                                       cf-\u003etid(10) \u003c= flush_tid(10),                                       detaches cf from i_cap_flush_list                                       drops i_ceph_lock                                       ceph_free_cap_flush(cf) \u003c- frees it!   acquires i_ceph_lock     \u003c---   for-loop advances:     cf = list_next_entry(cf, i_list)       -- UAF on freed cf-\u003ei_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.",
  "id": "DEBIAN-CVE-2026-89655",
  "modified": "2026-09-15T08:47:24.220504496Z",
  "published": "2026-09-11T20:19:51.683Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-89655"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-89655"
  ]
}