{
  "affected": [
    {
      "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:  perf: Fix use-after-free when perf mmap() revival races with the last munmap()  perf_mmap_close() drops rb-\u003emmap_count *without* holding event-\u003emmap_mutex (the refcount_dec_and_test() right before the refcount_dec_and_mutex_lock() of event-\u003emmap_count). A concurrent perf_mmap_rb() can slot its entire \"revival\" path into that window (perf_mmap holds event-\u003emmap_mutex for its whole duration, including rb_alloc):    munmap side (perf_mmap_close)          mmap side (perf_mmap_rb)   -----------------------------------    --------------------------------   rb-\u003emmap_count 1 -\u003e 0   (no lock)      (holds event-\u003emmap_mutex)                                          inc_not_zero(rb-\u003emmap_count) fails                                          ring_buffer_attach(event, NULL)                                          rb_alloc() + attach new rb                                          refcount_set(\u0026event-\u003emmap_count, 1)   lock; event-\u003emmap_count 1 -\u003e 0   ring_buffer_attach(event, NULL)   ring_buffer_put() -\u003e frees the *new* rb  The revival's refcount_set(\u0026event-\u003emmap_count, 1) is an invisible 1 -\u003e 1 write: the close frees the just-revived buffer although the other process still has it mapped -- a page-level use-after-free allowing local privilege escalation to root by any unprivileged user (default kernel.perf_event_paranoid=2).  Swap the order of the two counter updates: event-\u003emmap_count is dropped first via refcount_dec_and_mutex_lock(), so its 1 -\u003e 0 transition and the ring_buffer_attach() stay serialized with perf_mmap(). rb-\u003emmap_count == 0 then implies every event using the buffer is detached already, so the result of the rb-\u003emmap_count drop can gate the remaining teardown directly and detach_rest is no longer needed.  An earlier fix for this race from Kyle Zeng and David Lee takes event-\u003emmap_mutex around both counter updates [0]; here the not-last close stays lockless.",
  "id": "DEBIAN-CVE-2026-89791",
  "modified": "2026-09-17T04:47:34.459435577Z",
  "published": "2026-09-16T09:17:09.930Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-89791"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-89791"
  ]
}