CVE-2025-68798: Linux Kernel Race Condition Vulnerability

CVE-2025-68798 Overview

A race condition vulnerability has been discovered in the Linux kernel's AMD performance monitoring subsystem (perf/x86/amd). The vulnerability exists in the amd_pmu_enable_all() function where cpuc->events[idx] can become NULL due to a subtle race condition with the NMI handler's throttle mechanism (NMI->throttle->x86_pmu_stop()). This can lead to a General Protection Fault (GPF) when attempting to enable performance monitoring events on AMD processors.

The issue was identified through Syzkaller fuzzing, which reported a GPF in amd_pmu_enable_all with a null pointer dereference in the address range 0x00000000000001a0-0x00000000000001a7. This vulnerability affects systems running Linux kernels with AMD processors where performance monitoring is active.

Critical Impact
Local attackers may be able to trigger a kernel panic or system crash by exploiting this race condition in the AMD performance monitoring subsystem, potentially causing denial of service on affected systems.

Affected Products

Linux Kernel (AMD x86 systems with perf subsystem enabled)
Systems running kernel version 6.12.0-rc1 and potentially earlier versions
AMD processor-based systems utilizing performance event monitoring

Discovery Timeline

2026-01-13 - CVE CVE-2025-68798 published to NVD
2026-01-13 - Last updated in NVD database

Technical Details for CVE-2025-68798

Vulnerability Analysis

This vulnerability is classified as a Race Condition combined with a Null Pointer Dereference. The issue occurs in the AMD-specific performance monitoring unit (PMU) code within the Linux kernel's arch/x86/events/amd/core.c file.

The race condition manifests when the NMI (Non-Maskable Interrupt) handler invokes the throttle mechanism through the call chain NMI->throttle->x86_pmu_stop(). During this process, cpuc->events[idx] can be set to NULL. If amd_pmu_enable_all() attempts to access this event structure without first checking for NULL, a General Protection Fault occurs.

The Syzkaller-generated crash report shows the fault occurring at RIP: 0010:x86_pmu_enable_event with a null pointer dereference when attempting to access memory at offset 0x1a0. The call trace reveals the issue propagates through amd_pmu_enable_all() -> x86_pmu_enable() -> event_sched_out() -> __perf_remove_from_context().

Root Cause

The root cause is a missing NULL check in amd_pmu_enable_all() before attempting to enable performance monitoring events. When the NMI handler's throttle mechanism calls x86_pmu_stop(), it can clear the event pointer at cpuc->events[idx]. If amd_pmu_enable_all() is concurrently executing and attempts to dereference this pointer without validation, a kernel GPF results.

This is an AMD-specific issue because the Intel PMU implementation handles this scenario differently. The KASAN (Kernel Address Sanitizer) output confirms this is a null pointer dereference in the specified memory range.

Attack Vector

The attack vector requires local access to the system with the ability to utilize the performance monitoring subsystem. An attacker with sufficient privileges to create and manipulate perf events could potentially trigger this race condition by:

Creating multiple performance monitoring events
Generating sufficient system load to trigger NMI throttling
Exploiting the timing window where the event pointer becomes NULL but is still accessed

The crash occurs in kernel context during interrupt handling, making it particularly impactful for system stability.

Detection Methods for CVE-2025-68798

Indicators of Compromise

Kernel panic or system crash logs containing "general protection fault" with references to amd_pmu_enable_all or x86_pmu_enable_event
KASAN reports indicating null pointer dereference in range 0x00000000000001a0-0x00000000000001a7
NMI handler warnings showing "perf_event_nmi_handler took too long to run"
Kernel oops messages with call traces involving perf/x86/amd code paths
System instability or unexpected reboots on AMD-based systems under performance monitoring workloads

Detection Strategies

Monitor kernel logs for GPF events with stack traces involving amd_pmu_enable_all(), x86_pmu_enable(), or event_sched_out()
Implement kernel crash dump analysis to identify null pointer dereferences in the AMD PMU subsystem
Deploy kernel live patching monitoring to detect unpatched systems running vulnerable kernel versions
Use perf subsystem monitoring to detect anomalous behavior patterns that may indicate exploitation attempts

Monitoring Recommendations

Enable kernel panic logging and crash dump collection for post-incident analysis
Monitor for repeated system crashes or instability on AMD-based infrastructure
Implement alerting for KASAN or UBSAN reports in kernel logs if running debug-enabled kernels
Track NMI handler latency warnings as potential precursors to exploitation

How to Mitigate CVE-2025-68798

Immediate Actions Required

Apply the kernel patches provided in the referenced commits to add NULL checking before event enable operations
Consider temporarily disabling performance monitoring on critical AMD systems until patches are applied
Restrict access to the perf subsystem using kernel.perf_event_paranoid sysctl settings
Monitor systems for crash events and implement automatic restart procedures to maintain availability

Patch Information

The Linux kernel maintainers have released patches across multiple stable kernel branches. The fix adds a NULL check for the event pointer in amd_pmu_enable_all() before attempting to enable the event. The following commits contain the fix:

Organizations should update to kernel versions containing these fixes through their distribution's package management system.

Workarounds

Increase kernel.perf_event_paranoid to 2 or higher to restrict perf event access to root only
Limit user access to the perf subsystem via capabilities (CAP_PERFMON, CAP_SYS_ADMIN)
Consider disabling performance monitoring counters on AMD systems in production environments until patching is complete
Implement process sandboxing to limit which applications can create perf events

bash

# Configuration example
# Restrict perf_event access to root only
echo 2 > /proc/sys/kernel/perf_event_paranoid

# Alternative: Set via sysctl for persistence
echo "kernel.perf_event_paranoid = 2" >> /etc/sysctl.d/99-security.conf
sysctl -p /etc/sysctl.d/99-security.conf

# Verify the setting
sysctl kernel.perf_event_paranoid