CVE-2026-97947 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
x86/amd_node: Fix potential NULL pointer dereference
amd_smn_read/write() are exported functions around __amd_smn_rw(), so they are always available even if amd_smn_init() fails. In that case, 'amd_roots' is NULL and __amd_smn_rw() will access uninitialized memory.
Then, commit:
83518453074d ("x86/amd_node: Add SMN offsets to exclusive region access")
added the 'smn_exclusive' flag, which indicated the calls to pci_request_config_region_exclusive() succeeded, to prevent concurrent userspace access.
Commit:
0a4b61d9c2e4 ("x86/amd_node: Fix AMD root device caching")
re-ordered initialization so pci_request_config_region_exclusive() is called earlier and a failure exits amd_smn_init() before allocating 'amd_roots'. The setting of 'smn_exclusive' moved to the end of amd_smn_init(), after 'amd_roots' is allocated. It became redundant and can be removed.
Replace 'smn_exclusive' with directly checking 'amd_roots', to fix a potential NULL pointer dereference and to simplify the logic.
[ bp: Reorg commit message, touchup comment. ]
[ mingo: Rebase & further touchups. ]
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel vulnerability identified in the x86 AMD node driver involves a critical potential NULL pointer dereference within the System Management Node (SMN) access functions. The core issue stems from an initialization sequence flaw where exported helper functions amd_smn_read and amd_smn_write, which wrap the internal __amd_smn_rw function, remain available for invocation even if the primary initialization routine amd_smn_init fails to complete successfully. When amd_smn_init encounters a failure condition prior to allocating memory for the amd_roots data structure, this pointer remains NULL or uninitialized. Consequently, any subsequent call to these exported functions will attempt to access invalid memory through __amd_smn_rw, leading to kernel panics or undefined behavior due to dereferencing a null or garbage pointer.
The root cause is traced back to historical changes in the initialization logic aimed at preventing concurrent userspace access via pci_request_config_region_exclusive. An earlier commit introduced the smn_exclusive flag to track whether this exclusive region request succeeded, intending to gate access based on that status. However, a subsequent reordering of the initialization sequence moved the call to pci_request_config_region_exclusive earlier in the process and ensured that failures would exit amd_smn_init before allocating amd_roots. This change rendered the smn_exclusive flag redundant because if the exclusive region request failed or was not yet established, the function should have already exited without setting up the necessary data structures. The presence of this unused flag created a misleading state where code paths could proceed assuming valid resources were available when they were not.
The resolution involves removing the now-redundant smn_exclusive flag and replacing its usage with direct checks for the validity of the amd_roots pointer. By verifying that amd_roots is non-NULL before proceeding with SMN read or write operations, the driver ensures that access attempts are only made after successful initialization and memory allocation. This fix not only eliminates the risk of NULL pointer dereference but also simplifies the control flow logic by removing unnecessary state tracking variables. The change aligns the code behavior with the actual lifecycle of the resource management in the AMD node driver, ensuring robustness against early failure scenarios during system boot or module loading.
From a security and standards perspective, this vulnerability corresponds to CWE-476 NULL Pointer Dereference, which occurs when software dereferences a pointer that it expects to be valid but is actually null. In the context of operating systems like Linux, such flaws can lead to denial of service through kernel crashes or potentially privilege escalation if an attacker can trigger the specific code path under controlled conditions where memory layout allows for exploitation beyond simple crash scenarios. The ATT&CK framework categorizes this type of issue under techniques related to exploiting software vulnerabilities during initial deployment or operation, specifically highlighting how improper input validation and state management in system-level components create attack surfaces.
Mitigation strategies primarily involve applying the upstream kernel patch that corrects the initialization order and removes the redundant flag. For systems running affected versions of the Linux kernel, administrators should ensure timely updates to incorporate this fix. Additionally, developers reviewing similar driver codebases should enforce strict checks for resource availability before accessing pointers derived from those resources. Implementing defensive programming practices such as validating pointer validity immediately after allocation or initialization calls can prevent similar classes of vulnerabilities in other subsystems. Regular static analysis and fuzz testing during the development lifecycle are recommended to detect these logical errors early, ensuring that exported functions do not expose internal state inconsistencies to external callers.