CVE-2026-43401: Linux Kernel Use-After-Free Vulnerability

CVE-2026-43401 Overview

CVE-2026-43401 is a NULL pointer dereference vulnerability in the Linux kernel's intel_pstate cpufreq driver. The flaw resides in the update_cpu_qos_request() function, which dereferences the cpudata pointer before validating that the associated policy is valid. On systems booted with the nosmt kernel parameter, all_cpu_data[cpu] is NULL for SMT sibling threads. Any invocation of update_qos_requests() on these CPUs triggers a NULL pointer dereference when the code attempts to access pstate.turbo_freq through the NULL cpudata pointer. The issue affects Linux kernel builds running on Intel platforms using the intel_pstate driver with simultaneous multithreading disabled.

Critical Impact
A local trigger of the cpufreq QoS update path on a nosmt-booted Intel system causes a kernel NULL pointer dereference, resulting in a kernel oops and denial of service.

Affected Products

Linux kernel intel_pstate cpufreq driver
Linux kernel builds running on Intel CPUs with nosmt boot parameter
Stable kernel branches receiving commits 42738dffb7b0, 6bfda7ce56e7, and ab39cc4cb8ce

Discovery Timeline

2026-05-08 - CVE-2026-43401 published to NVD
2026-05-12 - Last updated in NVD database

Technical Details for CVE-2026-43401

Vulnerability Analysis

The intel_pstate driver maintains per-CPU state in the all_cpu_data[] array. When the kernel boots with nosmt, SMT sibling threads are not brought online and their entries in all_cpu_data[] remain NULL. The update_cpu_qos_request() function reads cpudata->pstate.turbo_freq to initialize a local freq variable before checking whether the corresponding cpufreq policy and driver_data are valid. When the function executes against an offline SMT sibling, the unchecked dereference of cpudata produces a kernel NULL pointer access. The result is a kernel oops in the cpufreq QoS update path. This class of defect maps to [CWE-476] NULL Pointer Dereference and produces a denial-of-service condition through kernel panic on systems configured with strict panic-on-oops settings.

Root Cause

The root cause is an ordering bug. The function performs pointer dereference before validation. The freq variable is assigned from cpudata->pstate.turbo_freq ahead of the policy and driver_data validity checks. A secondary concern is that pstate.turbo_freq may be updated by intel_pstate_get_hwp_cap() after the original assignment, leaving freq stale even when cpudata is non-NULL.

Attack Vector

Triggering the defect requires reaching the update_qos_requests() code path on an affected system. This occurs through normal cpufreq QoS request operations from kernel subsystems or user-controlled interfaces that issue PM QoS frequency constraints. The vulnerability is local and requires the system to be booted with nosmt. There is no remote network attack surface, and exploitation yields denial of service rather than code execution or privilege escalation.

No verified exploit code is available. The upstream fix defers the freq assignment until after policy and driver_data have been validated. See the kernel commits at git.kernel.org commit 42738dffb7b0, git.kernel.org commit 6bfda7ce56e7, and git.kernel.org commit ab39cc4cb8ce for the authoritative patch content.

Detection Methods for CVE-2026-43401

Indicators of Compromise

Kernel oops or panic log entries referencing update_cpu_qos_request or intel_pstate in dmesg or /var/log/kern.log
Stack traces showing NULL pointer dereference originating from the cpufreq QoS update path
Unexpected reboots on Intel systems booted with nosmt correlated with PM QoS activity

Detection Strategies

Inventory Linux hosts using cat /proc/cmdline to identify systems booted with the nosmt parameter and confirm the active cpufreq driver via cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
Compare running kernel versions against the fixed stable branches identified by the three upstream commit hashes
Monitor kernel ring buffer and journald for oops signatures referencing intel_pstate symbols

Monitoring Recommendations

Forward kernel logs to a centralized log store and alert on BUG: kernel NULL pointer dereference events that include intel_pstate frames
Track host uptime regressions on Intel fleets running with nosmt, which is common in mitigations for SMT-based side channel attacks
Audit any in-house kernel modules or userspace daemons that submit frequent PM QoS frequency requests

How to Mitigate CVE-2026-43401

Immediate Actions Required

Apply the upstream stable kernel update containing commits 42738dffb7b0, 6bfda7ce56e7, or ab39cc4cb8ce on all affected Intel hosts
Reboot impacted systems after kernel package upgrades to load the patched image
Prioritize patching for systems that depend on the nosmt boot parameter for security hardening

Patch Information

The fix defers the freq variable assignment in update_cpu_qos_request() until after the policy and driver_data pointers have been validated. This ordering change eliminates the NULL pointer dereference when all_cpu_data[cpu] is NULL for offline SMT siblings and also ensures freq reflects any update made by intel_pstate_get_hwp_cap(). Distribution maintainers ship the fix through stable kernel updates referenced in the kernel.org stable commit 42738dffb7b0, kernel.org stable commit 6bfda7ce56e7, and kernel.org stable commit ab39cc4cb8ce.

Workarounds

Remove the nosmt parameter from the kernel command line where SMT is acceptable, since the NULL cpudata condition does not occur when SMT siblings are online
Switch the active cpufreq driver away from intel_pstate to acpi-cpufreq where supported, using intel_pstate=disable on the kernel command line
Restrict access to interfaces that submit PM QoS frequency requests on unpatched hosts until the kernel update is deployed

bash

# Verify exposure and apply mitigation
cat /proc/cmdline | grep -o 'nosmt'
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
uname -r

# Distribution patch examples
sudo apt update && sudo apt install --only-upgrade linux-image-$(uname -r)
sudo dnf update kernel
sudo reboot