CVE-2026-81015: platform/x86/amd/pmc: Fix LPS0 and debugfs leaks when STB init fails
In the Linux kernel, the following vulnerability has been resolved:
platform/x86/amd/pmc: Fix LPS0 and debugfs leaks when STB init fails
amdpmcprobe() registers the LPS0 s2idle handler with acpiregisterlps0dev() and creates the driver's debugfs directory before calling amdstbs2dinit(), which is the last step in probe that can fail.
When amdstbs2dinit() 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 pcidevput() and returns. This leaves amdpmcs2idledevops on the global lps0s2idledevopshead 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 acpiregisterlps0dev() and hits:
listadd corruption. next->prev should be prev, but was NULL. kernel BUG at lib/listdebug.c:29! acpiregisterlps0dev+0x44/0x80 amdpmcprobe+0x224/0x380 [amdpmc] platformprobe+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 amdstbs2dinit() error path. acpiunregisterlps0dev() is safe to call unconditionally here: it is guarded on the same conditions as acpiregisterlps0dev(), which is exactly what amdpmcremove() already relies on.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for the faulty cleanup path to be reached?
The final probe step, amd_stb_s2d_init(), must fail after the LPS0 s2idle handler has been registered and the debugfs directory has been created. Reported failure examples include inability to ioremap the S2D telemetry region on a long-running system or rejection of S2D setup by the SMU.
What can happen after this initialization failure?
The LPS0 handler remains registered even though its devm-managed backing resources have been torn down, and the debugfs directory is leaked. A subsequent s2idle transition can call into the torn-down driver state even without reloading the module.
How might an affected system be identified?
Reloading the module after the failed initialization can trigger list corruption in acpi_register_lps0_dev(), including a "list_add corruption. next->prev should be prev, but was NULL" message and a kernel BUG at lib/list_debug.c:29. The stack trace can include acpi_register_lps0_dev, amd_pmc_probe, and amd_pmc.
What should be avoided if the fix cannot be applied immediately?
After an amd_stb_s2d_init() failure, avoid reloading the module, since reload can traverse the corrupted LPS0 registration list and cause a kernel BUG. Avoiding subsequent s2idle transitions also prevents the stale handler from being invoked against torn-down driver state.