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…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…