CVE-2026-53121

What it actually does

This vulnerability is a Linux kernel memory leak in the AMD P-State driver path amd_pstate_epp_cpu_init(). If setting the Energy Performance Preference fails, the function returns without freeing an allocated per-CPU cpudata object. The leaked memory remains allocated in kernel space until reboot. In practical terms, impact is limited to resource exhaustion: repeated execution of the failing initialization path, such as through driver initialization or CPU hotplug-related activity on affected AMD systems using amd-pstate EPP mode, could gradually consume kernel memory and degrade system stability. There is no indication from the provided data that this enables code execution, privilege escalation, or data disclosure.

Why it matters to the business

Affected Linux systems running the AMD P-State driver could experience degraded performance, instability, or denial of service if the leak is repeatedly triggered. The most likely business consequence is reduced availability of Linux workloads on impacted AMD-based servers, workstations, or appliances, potentially requiring service restarts or full reboots to recover leaked kernel memory. The EPSS score is very low, the issue is not in CISA KEV, and no exploit maturity is reported, so broad active exploitation is unlikely; however, kernel availability bugs should still be addressed through normal Linux kernel update cycles, especially for production systems where uptime is critical.

How an attack unfolds

An attacker would first need access to a system where the affected Linux kernel is running on compatible AMD hardware with the amd-pstate EPP code path available. The attacker would then attempt to cause amd_pstate_epp_cpu_init() to run and fail while setting the EPP value. If this failure path can be triggered repeatedly, each failed initialization leaks a cpudata allocation in kernel memory. Over time, repeated leaks may reduce available kernel memory and cause system instability, degraded service performance, failed allocations, or a crash. This is a denial-of-service scenario rather than a direct compromise path, and exploitation depends heavily on local conditions, kernel configuration, AMD platform support, and whether an unprivileged or privileged user can repeatedly exercise the relevant driver or CPU initialization path.

How to fix it

Apply a Linux kernel update that includes the fix for the amd-pstate memory leak in amd_pstate_epp_cpu_init(). If vendor-specific packages are used, install the fixed kernel provided by the operating system or appliance vendor once available, then reboot into the updated kernel. Because no exact affected products or fixed versions were provided, track the relevant distribution advisories for this CVE and for the upstream amd-pstate fix. As a temporary mitigation where patching is not immediately possible, reduce exposure by limiting local administrative access, restricting CPU hotplug and power-management control interfaces to trusted administrators, avoiding unnecessary amd-pstate driver reloads, and considering an alternate CPU frequency scaling driver or disabling amd-pstate EPP mode only if operationally acceptable and supported by the platform. Temporary mitigations should be validated carefully because power-management changes can affect performance, power use, and thermal behavior.

How to confirm the fix worked

Confirm that systems have booted into a kernel build containing the amd_pstate_epp_cpu_init() cleanup fix. Validate with the operating system vendor advisory, kernel changelog, or source package diff showing that cpudata is freed on the EPP-setting failure path. On running systems, verify the active kernel version with standard OS tooling such as uname and package-manager inventory, and confirm the system was rebooted after the update. For exposure validation, check whether the amd-pstate driver is present and active, whether EPP mode is enabled, and whether the platform uses AMD processors. For operational validation, monitor kernel logs and memory metrics while exercising normal CPU power-management behavior; after remediation, repeated EPP initialization failures should not produce a sustained increase in unreclaimable kernel memory attributable to this path.

Typical attack path

1. Identify a Linux system using an affected kernel with AMD P-State EPP support enabled.
2. Confirm the system is running on AMD hardware where the amd-pstate driver is active or can be activated.
3. Find a way to repeatedly invoke the amd_pstate_epp_cpu_init() path, such as through CPU hotplug, cpufreq policy initialization, driver reload, or related power-management operations, subject to local permissions and kernel configuration.
4. Force or wait for EPP setting to fail during initialization.
5. Repeat the failing initialization path to accumulate unreleased kernel memory allocations.
6. Monitor for reduced available memory, allocation failures, degraded performance, service disruption, or kernel instability.

How to detect it

To determine whether this issue may have been exploited or triggered, review kernel logs, system journals, audit logs, and endpoint telemetry for repeated amd-pstate initialization errors, EPP-setting failures, CPU frequency policy reinitialization, CPU hotplug events, driver reloads, and unexplained kernel memory exhaustion. Relevant log sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd-journald kernel facility logs, auditd records for writes to sysfs CPU online/offline controls, and EDR telemetry for privileged commands interacting with CPU power-management interfaces. Look for repeated sequences involving amd_pstate or amd-pstate-epp errors followed by increasing slab or unreclaimable kernel memory, allocation failures, OOM events, hung tasks, service crashes, or host reboots. Because this vulnerability is a memory leak with no unique exploit payload, detection is behavioral rather than signature-based; a single amd-pstate error is not sufficient to prove exploitation, but repeated forced initialization failures combined with memory pressure is suspicious. Also investigate administrative commands or automation repeatedly modifying CPU online state, cpufreq governors, EPP settings, or kernel module state around the time memory pressure began.

• amd_pstate_epp_cpu_init
• amd-pstate
• amd_pstate
• energy_performance_preference
• /sys/devices/system/cpu/amd_pstate/
• /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference
• /sys/devices/system/cpu/cpu*/online
• /sys/devices/system/cpu/cpufreq/
• modprobe amd_pstate
• rmmod amd_pstate
• CPU hotplug
• Out of memory
• oom-killer
• page allocation failure
• Memory allocation failure
• hung task
• kernel: amd_pstate
• kernel: amd-pstate
• dmesg: amd_pstate
• cpupower frequency-set
• cpupower set

What your security team should do

• Prioritize inventory of Linux systems running on AMD hardware with amd-pstate or amd-pstate EPP enabled.
• Track vendor kernel advisories and schedule kernel updates that include the amd_pstate_epp_cpu_init() memory leak fix.
• Reboot patched systems and verify they are running the fixed kernel, not only that the package is installed.
• For high-availability production systems, include this fix in the next planned maintenance window unless vendor guidance indicates higher urgency.
• Restrict access to CPU hotplug, cpufreq, kernel module loading, and power-management controls to trusted administrators.
• Monitor affected systems for unusual kernel memory growth, repeated amd-pstate errors, CPU hotplug activity, or service instability.
• Do not treat this as evidence of remote compromise by itself; focus detection on local abuse patterns and availability symptoms.
• If unexplained instability is observed on AMD Linux hosts, preserve kernel logs, audit logs, and memory telemetry before rebooting where operationally feasible.