CVE-2026-81016 in Linux
Summary
by MITRE • 09/12/2026
In the Linux kernel, the following vulnerability has been resolved:
platform/x86/amd/pmc: Propagate SMU errors and validate S2D address
amd_stb_s2d_init() 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 S2D_PHYS_ADDR_LOW/HIGH return values are ignored, so on failure phys_addr_low/hi are left uninitialised and the assembled address is passed straight to devm_ioremap(). When the SMU leaves them at zero this maps physical address 0 and trips the ioremap-on-RAM warning:
amd_pmc 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 devm_ioremap().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/12/2026
The vulnerability in question resides within the AMD Platform Management Controller (PMC) driver for Linux, specifically affecting the initialization routine amd_stb_s2d_init. This function is responsible for establishing communication with the System Management Unit to set up shared memory regions used by various power management and telemetry features on AMD processors. The core technical flaw involves two distinct but related issues: improper error handling of SMU command responses and a lack of validation for physical address pointers returned by those commands. When the driver invokes specific S2D (Shared-to-Device) SMU commands, it fails to check the return values indicating success or failure. Instead, any non-zero result from these hardware calls is broadly categorized as an input/output error (-EIO), which obscures the actual underlying cause of the failure reported by the firmware. This masking effect prevents system administrators and developers from diagnosing why a particular SMU command was rejected, such as due to invalid parameters or unsupported features on specific silicon revisions.
A more critical aspect of this vulnerability is the handling of physical address variables associated with these commands. The driver retrieves low and high 32-bit components of a physical address from the SMU response but does not validate whether these values are valid before assembling them into a full 64-bit pointer. If the SMU command fails, it may leave these address fields uninitialized or set to zero. Consequently, when the code proceeds to call devm_ioremap with this assembled address, it attempts to map physical address zero if both components were left at zero. Mapping physical address zero is a severe operational error because this memory region typically contains critical system data and can trigger hardware protection mechanisms. The kernel detects this invalid mapping attempt and generates a warning indicating an ioremap on RAM at 0x0000000000000000, which disrupts normal operation and indicates that the driver is interacting with memory it should not access.
From a security perspective, this vulnerability aligns with CWE-252: Unchecked Return Value, as the code ignores critical return codes from hardware interface functions. Furthermore, the attempt to map physical address zero relates to CWE-789: Memory Allocation with Excessive Size or CWE-1341: Improper Validation of Specified Identifier, specifically regarding invalid memory addresses. In terms of MITRE ATT&CK techniques, this scenario reflects aspects of T1055: Process Injection via Dynamic Library Loading if the mapped region were exploited for code execution, although in its current state, it primarily represents a stability and reliability issue rather than an exploitable privilege escalation vector. The lack of input validation allows faulty firmware responses to propagate into kernel memory management subsystems, potentially leading to system instability or crashes.
The operational impact includes potential system hangs, kernel panics, or the generation of excessive warning logs that can obscure other critical issues during troubleshooting. While direct exploitation for arbitrary code execution is unlikely given the nature of mapping physical address zero, the vulnerability degrades system reliability and complicates diagnostics on AMD platforms utilizing this PMC driver. To mitigate these risks, developers must implement strict validation checks after every SMU command invocation. This includes verifying that return codes indicate success before proceeding to use any data returned by those commands. Additionally, explicit checks should be added to ensure that the assembled physical address is non-zero and falls within valid memory ranges prior to calling devm_ioremap. By propagating specific error codes rather than generic I/O errors, administrators gain visibility into actual hardware failures, allowing for more accurate troubleshooting and preventing invalid memory mappings from occurring in the first place.