CVE-2026-23435
MediumCVSS 5.5Exploitation Probability (EPSS)
Low risk2th percentile - higher than 2% of all known CVEs
Summary
A bug was found in the Linux kernel's PMU (Performance Monitoring Unit) handling for AMD EPYC processors. The issue is that the event pointer setup in x86_pmu_enable() occurs too late, leading to a race condition and a NULL pointer dereference in the NMI (Non-Maskable Interrupt) handler. This results in a kernel crash.
Risk Assessment
The organization faces the risk of system crashes on AMD EPYC processors during intensive performance monitoring (e.g., using perf tools). An attacker could deliberately trigger PMU overload to cause a kernel crash and service disruption (Denial of Service).
Recommendation
Immediately apply the Linux kernel patch addressing CVE-2026-23435. It is recommended to update to a kernel version containing the fix commit (moving the event pointer assignment before the PERF_HES_ARCH check).
Other vulnerabilities in Linux kernel
See all- CVE-2026-98164Unknown
In the Linux kernel, KVM x86/mmu's kvm_gfn_is_write_tracked() only checks the supplied memslot, but page tracking is per-address-space and shadow pages are shared across address spaces. With SMM, a GFN can be write-tracked in one address space and appear untracked in another. The fix checks the supplied slot first, then the slot for the other address space, preventing mmu_try_to_unsync_pages() from marking an upper-level shadow page unsync and triggering a BUG in pte_list_remove().
- CVE-2026-98048Unknown
In the Linux kernel's BPF subsystem, mark_fastcall_pattern_for_call() must ensure that a matched "spill; call; fill" instruction series is not interrupted by a jump. Otherwise the rewrite applied by bpf_remove_fastcall_spills_fills() is unsound. The fix records instructions targeted by jumps in insn_aux_data[*].jump_target and uses this flag to stop growing a pattern.
- CVE-2026-98047Unknown
In the Linux kernel's BPF subsystem, in_rbtree_lock_required_cb() only checks the innermost verifier frame, so rbtree callback restrictions disappear in a nested static subprogram call frame. The subprogram can unlock the tree, remove and drop the node being compared, then relock, leading to freed memory being linked into the tree.
- CVE-2026-98046Unknown
In the Linux kernel's BPF subsystem, bpf_btf_find_by_name_kind() returns a new BTF object fd through __btf_new_fd(), which reaches anon_inode_getfd() that can sleep while allocating or expanding the current task fd table. The helper prototype does not set might_sleep, so the verifier allows the helper in non-sleepable contexts such as BPF timer callbacks.
- CVE-2026-98045Unknown
In the Linux kernel, a BPF verifier vulnerability affects stack helpers that may block on filesystem reads (e.g., resolving build IDs) but were not marked as sleepable. The verifier could still allow these helpers from non-sleepable regions such as RCU or preemption-disabled sections.
- CVE-2026-98044Unknown
In the Linux kernel, the BPF verifier mishandled legacy packet-load instructions (BPF_LD_ABS/BPF_LD_IND) reached from callbacks, triggering a verifier bug warning and an -EFAULT on BPF_PROG_LOAD. A privileged program loader could trigger this issue.
- CVE-2026-98043Unknown
In the Linux kernel, the BPF verifier incorrectly inferred that a pointer with an unbounded offset is non-NULL based solely on its type. As a result, a BPF program could pass verification while a NULL pointer dereference occurred at runtime.
- CVE-2026-98042Unknown
In the Linux kernel, the BPF verifier could resurrect a scalar id dropped by collect_linked_regs() because snapshots of compared registers were taken before linked registers were collected. This could lead to range inconsistencies and precision propagation issues.
- CVE-2026-98041High
In the Linux kernel, the BPF verifier incorrectly predicted the outcome of pointer vs zero comparisons in JMP32 instructions, failing to distinguish BPF_JMP from BPF_JMP32 comparisons. This led to incorrect inference that a jump is always taken.
- CVE-2026-98040Unknown
In the Linux kernel, the BPF verifier did not mark the zero register as precise for a register-form NULL check. As a result, one path was pruned and the program could dereference a zero pointer at runtime.
Original NVD description (English source)
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: <NMI> 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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS