CVE-2026-81016

The AMD Platform Management Controller driver (drivers/platform/x86/amd/pmc) in the Linux kernel does not check the return values of SMU 'Spill-to-DRAM' (S2D) commands in amd_stb_s2d_init(), and ignores the returned S2D_PHYS_ADDR_LOW/HIGH values. When the SMU refuses a command (e.g., 'SMU cmd failed. err: 0xff'), phys_addr_low/hi are left uninitialized or zero, and the assembled address is passed straight to devm_ioremap(), which can map physical address 0 — RAM itself — tripping the kernel's ioremap-on-RAM warning and masking the real error code as -EIO. The flaw is triggered by SMU/firmware misbehavior during driver initialization on supported AMD platforms rather than by a conventional attacker-controlled input, though the CVSS 3.1 score of 7.7 rates it local-vector with no privileges required and high confidentiality and availability impact. Affected systems are those running kernel builds with the unfixed amd_pmc S2D code on AMD hardware that exposes the PMC device (the log example shows ACPI ID AMDI000B). There is no public proof of concept, no known exploitation in the wild, and the CVE is not on the CISA KEV list.

What to do: Update to a kernel that includes the fix — it now checks each SMU command's return value and rejects a zero physical address before calling devm_ioremap() — via your distribution's stable updates as they land. Keep platform BIOS/AGESA firmware current, since SMU misbehavior is what triggers the faulty path. On AMD systems, check dmesg for 'SMU cmd failed. err:' and 'ioremap on RAM' warnings to determine whether the buggy path has been hit.