UBUNTU-CVE-2026-81015: High severity ubuntu/linux-hwe-edge vulnerability
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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
On the amd_stb_s2d_init() failure path in amd_pmc_probe(), remove the debugfs directory and call acpi_unregister_lps0_dev() to undo the earlier LPS0 registration before returning; acpi_unregister_lps0_dev() may be called unconditionally here.
Event History
Frequently Asked Questions
Which systems are exposed to the failure path?
The affected path is in the AMD PMC platform driver. Exposure requires amd_pmc_probe() to reach amd_stb_s2d_init() and for that final initialization step to fail, such as when the S2D telemetry region cannot be ioremapped or the SMU rejects S2D setup.
What can trigger the most visible failure after the initialization error?
Reloading the AMD PMC module after the failed initialization can walk a corrupted LPS0 handler list and trigger list corruption followed by a kernel BUG. A subsequent s2idle transition can also call into torn-down driver state even without a module reload.
What operational precautions are supported if an update cannot be applied immediately?
On systems where AMD PMC S2D initialization has failed, avoid reloading the amd_pmc module and avoid subsequent s2idle transitions. The vulnerable error path leaves both an LPS0 registration and a debugfs directory behind while the associated managed resources are removed.