GHSA-4RRH-P933-RF74

Vulnerability from github – Published: 2026-04-03 18:31 – Updated: 2026-04-23 21:31
VLAI?
Details

In the Linux kernel, the following vulnerability has been resolved:

perf/x86: Move event pointer setup earlier in x86_pmu_enable()

A production AMD EPYC system crashed with a NULL pointer dereference in the PMU NMI handler:

BUG: kernel NULL pointer dereference, address: 0000000000000198 RIP: x86_perf_event_update+0xc/0xa0 Call Trace: amd_pmu_v2_handle_irq+0x1a6/0x390 perf_event_nmi_handler+0x24/0x40

The faulting instruction is cmpq $0x0, 0x198(%rdi) with RDI=0, corresponding to the if (unlikely(!hwc->event_base)) check in x86_perf_event_update() where hwc = &event->hw and event is NULL.

drgn inspection of the vmcore on CPU 106 showed a mismatch between cpuc->active_mask and cpuc->events[]:

active_mask: 0x1e (bits 1, 2, 3, 4) events[1]: 0xff1100136cbd4f38 (valid) events[2]: 0x0 (NULL, but active_mask bit 2 set) events[3]: 0xff1100076fd2cf38 (valid) events[4]: 0xff1100079e990a90 (valid)

The event that should occupy events[2] was found in event_list[2] with hw.idx=2 and hw.state=0x0, confirming x86_pmu_start() had run (which clears hw.state and sets active_mask) but events[2] was never populated.

Another event (event_list[0]) had hw.state=0x7 (STOPPED|UPTODATE|ARCH), showing it was stopped when the PMU rescheduled events, confirming the throttle-then-reschedule sequence occurred.

The root cause is commit 7e772a93eb61 ("perf/x86: Fix NULL event access and potential PEBS record loss") which moved the cpuc->events[idx] assignment out of x86_pmu_start() and into step 2 of x86_pmu_enable(), after the PERF_HES_ARCH check. This broke any path that calls pmu->start() without going through x86_pmu_enable() -- specifically the unthrottle path:

perf_adjust_freq_unthr_events() -> perf_event_unthrottle_group() -> perf_event_unthrottle() -> event->pmu->start(event, 0) -> x86_pmu_start() // sets active_mask but not events[]

The race sequence is:

  1. A group of perf events overflows, triggering group throttle via perf_event_throttle_group(). All events are stopped: active_mask bits cleared, events[] preserved (x86_pmu_stop no longer clears events[] after commit 7e772a93eb61).

  2. While still throttled (PERF_HES_STOPPED), x86_pmu_enable() runs due to other scheduling activity. Stopped events that need to move counters get PERF_HES_ARCH set and events[old_idx] cleared. In step 2 of x86_pmu_enable(), PERF_HES_ARCH causes these events to be skipped -- events[new_idx] is never set.

  3. The timer tick unthrottles the group via pmu->start(). Since commit 7e772a93eb61 removed the events[] assignment from x86_pmu_start(), active_mask[new_idx] is set but events[new_idx] remains NULL.

  4. A PMC overflow NMI fires. The handler iterates active counters, finds active_mask[2] set, reads events[2] which is NULL, and crashes dereferencing it.

Move the cpuc->events[hwc->idx] assignment in x86_pmu_enable() to before the PERF_HES_ARCH check, so that events[] is populated even for events that are not immediately started. This ensures the unthrottle path via pmu->start() always finds a valid event pointer.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-23435"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-03T16:16:25Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86: Move event pointer setup earlier in x86_pmu_enable()\n\nA production AMD EPYC system crashed with a NULL pointer dereference\nin the PMU NMI handler:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000198\n  RIP: x86_perf_event_update+0xc/0xa0\n  Call Trace:\n   \u003cNMI\u003e\n   amd_pmu_v2_handle_irq+0x1a6/0x390\n   perf_event_nmi_handler+0x24/0x40\n\nThe faulting instruction is `cmpq $0x0, 0x198(%rdi)` with RDI=0,\ncorresponding to the `if (unlikely(!hwc-\u003eevent_base))` check in\nx86_perf_event_update() where hwc = \u0026event-\u003ehw and event is NULL.\n\ndrgn inspection of the vmcore on CPU 106 showed a mismatch between\ncpuc-\u003eactive_mask and cpuc-\u003eevents[]:\n\n  active_mask: 0x1e (bits 1, 2, 3, 4)\n  events[1]:   0xff1100136cbd4f38  (valid)\n  events[2]:   0x0                 (NULL, but active_mask bit 2 set)\n  events[3]:   0xff1100076fd2cf38  (valid)\n  events[4]:   0xff1100079e990a90  (valid)\n\nThe event that should occupy events[2] was found in event_list[2]\nwith hw.idx=2 and hw.state=0x0, confirming x86_pmu_start() had run\n(which clears hw.state and sets active_mask) but events[2] was\nnever populated.\n\nAnother event (event_list[0]) had hw.state=0x7 (STOPPED|UPTODATE|ARCH),\nshowing it was stopped when the PMU rescheduled events, confirming the\nthrottle-then-reschedule sequence occurred.\n\nThe root cause is commit 7e772a93eb61 (\"perf/x86: Fix NULL event access\nand potential PEBS record loss\") which moved the cpuc-\u003eevents[idx]\nassignment out of x86_pmu_start() and into step 2 of x86_pmu_enable(),\nafter the PERF_HES_ARCH check. This broke any path that calls\npmu-\u003estart() without going through x86_pmu_enable() -- specifically\nthe unthrottle path:\n\n  perf_adjust_freq_unthr_events()\n    -\u003e perf_event_unthrottle_group()\n      -\u003e perf_event_unthrottle()\n        -\u003e event-\u003epmu-\u003estart(event, 0)\n          -\u003e x86_pmu_start()     // sets active_mask but not events[]\n\nThe race sequence is:\n\n  1. A group of perf events overflows, triggering group throttle via\n     perf_event_throttle_group(). All events are stopped: active_mask\n     bits cleared, events[] preserved (x86_pmu_stop no longer clears\n     events[] after commit 7e772a93eb61).\n\n  2. While still throttled (PERF_HES_STOPPED), x86_pmu_enable() runs\n     due to other scheduling activity. Stopped events that need to\n     move counters get PERF_HES_ARCH set and events[old_idx] cleared.\n     In step 2 of x86_pmu_enable(), PERF_HES_ARCH causes these events\n     to be skipped -- events[new_idx] is never set.\n\n  3. The timer tick unthrottles the group via pmu-\u003estart(). Since\n     commit 7e772a93eb61 removed the events[] assignment from\n     x86_pmu_start(), active_mask[new_idx] is set but events[new_idx]\n     remains NULL.\n\n  4. A PMC overflow NMI fires. The handler iterates active counters,\n     finds active_mask[2] set, reads events[2] which is NULL, and\n     crashes dereferencing it.\n\nMove the cpuc-\u003eevents[hwc-\u003eidx] assignment in x86_pmu_enable() to\nbefore the PERF_HES_ARCH check, so that events[] is populated even\nfor events that are not immediately started. This ensures the\nunthrottle path via pmu-\u003estart() always finds a valid event pointer.",
  "id": "GHSA-4rrh-p933-rf74",
  "modified": "2026-04-23T21:31:18Z",
  "published": "2026-04-03T18:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23435"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/886fa869153917d902784098922defa20c3a2fe5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8d5fae6011260de209aaf231120e8146b14bc8e0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c1dd1e2b722d3f1f2e4977dad8d1be78fdfb30cb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…