Look up another CVE · open CVE-2026-81015 in the interactive tracker
CVE-2026-81015
platform/x86/amd/pmc: Fix LPS0 and debugfs leaks when STB init fails
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem drivers/platform. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-81015 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/platform/x86/amd/pmc/pmc.c
- What this is
- AMD PMC DRIVERMAINTAINERS section matched on drivers/platform/x86/amd/pmc/ · platform-driver-x86@vger.kernel.org · Supported
- Kernel module
- amd_pmc
Check it on the machine
grep -wE 'CONFIG_AMD_PMC|CONFIG_X86' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w amd_pmcPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed. The build rule could not be established for 1 release, so nothing is claimed about those.
- bookworm?
- trixieMnot built on amd64/cloud-amd64, arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt/arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/cloud-amd64, arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- ?
- not established - no Makefile entry for the affected file
- M
- a module where it is built at all; some flavours do not build it
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switches
- CONFIG_AMD_PMC, CONFIG_X86
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/platform
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.12.112 | 6.12.112 | d201c09c2428 |
| 6.14 | 6.18.50 | bc9aa5fe21c3 |
| 6.14 | 7.2.4 | 30e5f4d0cd0b |
| 6.14 | 7.3 | 76f650a76d6a |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The flaw is in amd_pmc_probe() and the ACPI LPS0 s2idle callbacks on local AMD Ryzen platforms; there is no network, Bluetooth, or remote packet path into this platform driver.
- AC:LAttack complexity, low
- Once amd_stb_s2d_init() fails, the leaked LPS0 registration is deterministic; suspend then invokes the dangling handler, and a later bind or module reload list_add()s onto the already-linked or freed lps0_s2idle_devops_head node with no race the attacker must win.
- PR:LPrivileges required, low
- After the probe error path leaves amd_pmc_s2idle_dev_ops on the global LPS0 list, an unprivileged local-session user on AMD laptops can trigger s2idle via logind, idle-timeout, or lid-close without init-namespace root; user namespaces cannot reach this driver.
- UI:NUser interaction, none
- Exploitation needs no separate victim action such as mounting a filesystem or opening a device; the attacker requests suspend themselves, or automatic s2idle and driver reload/bind exercise the stale list unattended.
- S:UScope, unchanged
- The dangling LPS0 list node, use of torn-down ioremap/mutex state, and kernel list corruption remain in the host kernel; this is standard kernel memory corruption, not a VM escape, IOMMU bypass, or sandbox boundary crossing.
- C:HConfidentiality impact, high
- The stale acpi_s2idle_dev_ops stays on lps0_s2idle_devops_head after devm ioremap is torn down and after rmmod the ops object itself is freed; s2idle and list_add then read recycled vmalloc/module memory, a use-after-free disclosure primitive.
- I:HIntegrity impact, high
- Module reload list_add() writes through dangling next/prev pointers, and s2idle handlers issue MMIO writes and call prepare/check/restore through torn-down or freed module state, enabling control-flow hijack per kernel UAF guidance.
- A:HAvailability impact, high
- Reloading amd_pmc hits list_add corruption and kernel BUG in acpi_register_lps0_dev(), and the next s2idle transition oopses or hangs while walking the corrupted list or invoking the torn-down LPS0 handler.