HIGH Introduced in 6.14
amd_pmc LPS0 Leak
CVE-2026-81015
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI6.4MEDIUM
01Description
In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Fix LPS0 and debugfs leaks when STB init fails amd_pmc_probe() registers the LPS0 s2idle handler with acpi_register_lps0_dev() and creates the driver's debugfs directory before calling amd_stb_s2d_init(), which is the last step in probe that can fail. When amd_stb_s2d_init() fails (for example the S2D telemetry region cannot be ioremapped on a long-running system, or the SMU rejects the S2D setup) the error path only calls pci_dev_put() and returns. This leaves amd_pmc_s2idle_dev_ops on the global lps0_s2idle_devops_head list and leaks the debugfs directory, while the devm-managed resources backing the handler are torn down. Reloading the module then walks the corrupted list in acpi_register_lps0_dev() and hits: list_add corruption. next->prev should be prev, but was NULL. kernel BUG at lib/list_debug.c:29! acpi_register_lps0_dev+0x44/0x80 amd_pmc_probe+0x224/0x380 [amd_pmc] platform_probe+0x67/0x90 Even without a reload, the stale registration means the next s2idle transition calls into torn-down driver state. Unwind the debugfs directory and the LPS0 registration on the amd_stb_s2d_init() error path. acpi_unregister_lps0_dev() is safe to call unconditionally here: it is guarded on the same conditions as acpi_register_lps0_dev(), which is exactly what amd_pmc_remove() already relies on.
02KernelScan AI Analysis
Risk summary
A local attacker with root privileges can trigger a kernel panic or system instability by reloading the amd_pmc module after a failed STB initialization, which corrupts a global ACPI list. The vulnerability requires specific hardware (AMD platform with PMC support) and root access to exploit.
Vulnerability analysis
If the AMD platform power driver fails partway through initialization, the error path neglects to unregister a system power-management callback and remove a debug directory. This leaves a stale entry on a global kernel list after the backing resources have been freed. Reloading the driver then corrupts that list and causes a kernel crash. Even without reloading, the stale callback can be invoked during the next suspend-to-idle cycle, calling into freed driver memory. The fix cleans up both the callback and the debug directory when the initialization step fails. A local attacker with root access on affected AMD hardware can reach this flaw.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.18 | 6.14 | 6.18.50 | d201c09c2428 |
| 7.2 | 6.14 | 7.2.4 | bc9aa5fe21c3 |
| mainline | 6.14 | 7.3 | 30e5f4d0cd0b |
| cip/6.12 | 6.14 | 6.12.112-cip33 | d201c09c2428 |
04CIP Kernels
State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.
| CIP tree | State |
|---|---|
| cip/6.12 | Fixed in 6.12.112-cip33 |