{
  "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"
            },
            {
              "fixed": "6.12.111-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.2.6-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  perf/x86/intel/pt: Fix stop/start with no update  If pt_event_stop() is called without PERF_EF_UPDATE flag, then perf_aux_output_end() is not called.  A subsequent call to pt_event_start() will call perf_aux_output_begin() again which violates the rule against nesting and triggers a WARNING in perf_aux_output_begin().  Originally, pt_event_stop() was never called without PERF_EF_UPDATE, because the only code paths to do so are from event overflow, and Intel PT does not do that.  However the introduction of group throttling by commit 9734e25fbf5ae (\"perf: Fix the throttle logic for a group\") meant that an Intel PT event could be throttled if it was part of a group.  Throttling calls PMU  -\u003estop() / -\u003estart() callbacks without flags.  An example is when AUX area sampling is used. The following commands hit the issue:    echo 10000 \u003e /proc/sys/kernel/perf_event_max_sample_rate    perf record -F32000 --aux-sample -e '{intel_pt//u,cycles:u}' \\   -- bash -c 'for i in `seq 1 100000` ; do true ; done'  Use PERF_HES_UPTODATE to track whether perf_aux_output_begin() and perf_aux_output_end() are balanced.  A cleared PERF_HES_UPTODATE bit indicates that an AUX output context is still open.  Amend pt_event_start() / pt_event_stop() accordingly so that begin/end stay balanced:   - In non-snapshot mode, stop() always closes the buffer (the buffer may    have run out of space, and that accounting is done by the update), so    a following start() opens a fresh one as before.   - In snapshot/overwrite mode, stop() without PERF_EF_UPDATE leaves the    buffer open so that pt_event_snapshot_aux() can still copy from it,    and start() then only re-enables tracing instead of calling    perf_aux_output_begin() again.  Note that pt_event_del() calls pt_event_stop() with PERF_EF_UPDATE flag set (as is required by the documentation), so a final call to perf_aux_output_end() is assured.",
  "id": "DEBIAN-CVE-2026-93275",
  "modified": "2026-09-29T10:47:31.245895152Z",
  "published": "2026-09-24T16:17:24.667Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-93275"
    }
  ],
  "upstream": [
    "CVE-2026-93275"
  ]
}