CVE-2026-92492
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A Linux kernel bug on AMD processors can cause the computer to crash when power settings change at the same time as a CPU is turned off or on.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition in amd-pstate cpufreq driver allows NULL policy pointer from cpufreq_cpu_get() to be dereferenced in amd_pstate_power_supply_notifier() and amd_pstate_profile_set() during concurrent CPU hotplug or driver teardown, causing NULL pointer dereference.
Why it matters to the business
Unexpected kernel crashes or system instability on AMD platforms using dynamic EPP power management, leading to downtime and potential data loss in high-availability environments; low exploitability limits widespread impact but requires prompt patching on affected kernels.
How an attack unfolds
An attacker with local access races CPU offline events or cpufreq driver unload against power-supply notifier or profile-set paths; the missing NULL check lets the subsequent call to amd_pstate_get_balanced_epp() or amd_pstate_set_epp() dereference a NULL policy pointer.
How to fix it
Apply the upstream fix that adds explicit NULL checks returning NOTIFY_OK or -ENODEV; rebuild and boot a patched kernel; disable dynamic EPP features via cpufreq if immediate update is impossible.
How to confirm the fix worked
Confirm kernel source contains NULL guard in amd_pstate_power_supply_notifier and amd_pstate_profile_set before cpufreq_cpu_get result is used; run cpufreq hotplug stress tests while monitoring for NULL dereference oops; verify no crash under concurrent policy teardown.
Typical attack path
- Obtain local execution on target AMD Linux system
- Trigger rapid CPU hotplug or cpufreq policy teardown while power-supply notifier or profile callbacks execute
- Force cpufreq_cpu_get() to return NULL and pass it to unbalanced EPP functions
- Trigger NULL pointer dereference resulting in kernel panic or oops
How to detect it
Search kernel logs and dmesg for oops/panic strings containing amd_pstate_get_balanced_epp, amd_pstate_set_epp, or cpufreq_cpu_get NULL policy; correlate timestamps with CPU hotplug events in /var/log/kern.log or journalctl.
- amd_pstate_get_balanced_epp
- amd_pstate_set_epp
- NULL pointer dereference.*cpufreq_cpu_get
- amd_pstate_power_supply_notifier
What your security team should do
- Prioritize kernel update on all AMD systems within 30 days given publication age
- Audit boot logs for amd_pstate NULL dereference signatures after applying patch
- Consider disabling amd_pstate EPP dynamic mode on high-risk workloads until patched
- Monitor EPSS and KEV updates for any change in exploit maturity
The record
In the Linux kernel, the following vulnerability has been resolved: cpufreq/amd-pstate: handle missing policy in dynamic EPP callbacks cpufreq_cpu_get() returns NULL when no cpufreq policy is associated with the requested CPU, for example because the CPU is offline or the policy has already been torn down. Both amd_pstate_power_supply_notifier() and amd_pstate_profile_set() acquire a policy via cpufreq_cpu_get() and then pass that pointer to amd_pstate_get_balanced_epp() and amd_pstate_set_epp(), which dereference it unconditionally. A racing CPU hotplug or driver teardown can therefore lead to a NULL pointer dereference on either of these dynamic EPP paths. The third cpufreq_cpu_get() caller in this file, amd_pstate_verify(), already handles the NULL case. Bring the two new callers in line with that pattern: return NOTIFY_OK from the power-supply notifier (matching the other "nothing to do" exits) and -ENODEV from amd_pstate_profile_set() (the usual cpufreq error for a missing CPU policy). Found by code inspection; not tested on hardware.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|