KernelScan.io

HIGH Introduced in 6.14

amd_pmc LPS0 Leak

CVE-2026-81015

CVSS 7.8 / 10.0 NVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

KernelScan AI6.4MEDIUM

01

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.

02

Engine v0.6.0

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.

Affecteddrivers/platform/x86/amd/pmc/pmc.c (AMD PMC driver)

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.

03

BranchIntroducedFixed inPatch commit
6.186.146.18.50d201c09c2428
7.26.147.2.4bc9aa5fe21c3
mainline6.147.3-rc130e5f4d0cd0b