CVE-2026-81016: platform/x86/amd/pmc: Propagate SMU errors and validate S2D address
In the Linux kernel, the following vulnerability has been resolved:
platform/x86/amd/pmc: Propagate SMU errors and validate S2D address
amdstbs2dinit() discards the return value of several S2D SMU commands. When the SMU refuses a command (e.g. "SMU cmd failed. err: 0xff") the failure is only noticed indirectly - if at all - and reported as -EIO, masking the real error.
More seriously, the S2DPHYSADDRLOW/HIGH return values are ignored, so on failure physaddrlow/hi are left uninitialised and the assembled address is passed straight to devmioremap(). When the SMU leaves them at zero this maps physical address 0 and trips the ioremap-on-RAM warning:
amdpmc AMDI000B:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 13 PID: 4592 at arch/x86/mm/ioremap.c:...
Check the return value of each SMU command and propagate it, and reject a zero physical address before calling devmioremap().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.112 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.50 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.4 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - 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
Check the return value of every S2D SMU command in amd_stb_s2d_init() and propagate SMU failures, including the actual SMU error instead of masking it as -EIO.
- Compensating control
Reject a zero assembled S2D physical address before calling devm_ioremap().
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems running the Linux kernel code path for the AMD PMC driver and its S2D initialization are exposed when SMU commands fail. The provided data does not identify affected kernel versions or specific AMD platforms.
What condition triggers the unsafe mapping behavior?
The condition occurs when the S2D physical-address SMU commands fail and their return values are ignored. If the returned address fields remain zero, the driver can pass physical address 0 to devm_ioremap().
How can administrators tell whether they have encountered this problem?
Kernel logs may show an AMD PMC SMU command failure, such as "SMU cmd failed. err: 0xff", followed by an "ioremap on RAM" warning for an address range beginning at 0x0000000000000000. Earlier failures may also have been reported only as -EIO, masking the underlying SMU error.
What does the fix change?
The fix checks and propagates the return value of each S2D SMU command rather than masking failures as -EIO. It also rejects a zero physical address before calling devm_ioremap().