CVE-2026-97494 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: validate and share PSP fw_pri_buf copies via psp_copy_fw
Change psp_copy_fw from void to int: return -ENODEV when drm_dev_enter fails, and -EINVAL when the image size is zero or larger than the 1 MiB PSP private buffer.
Replace open-coded memset/memcpy into fw_pri_buf with psp_copy_fw.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability addressed in this update pertains to the AMDGPU driver within the Linux kernel, specifically involving the Platform Security Processor firmware handling mechanism known as psp_copy_fw. Historically, this function operated without returning a status code, which obscured potential failure conditions during the initialization and validation of firmware images. The core technical flaw lay in the lack of rigorous input validation for the size of the firmware image being processed against the constraints of the PSP private buffer, which is capped at one megabyte. Furthermore, the driver did not properly verify the availability or validity of the DRM device context before attempting to access shared buffers associated with the Platform Security Processor. This absence of checks created a scenario where invalid memory operations could occur if the device was in an inconsistent state or if malformed firmware data was supplied by user space or other kernel subsystems.
By modifying psp_copy_fw to return integer status codes, the driver now explicitly handles error conditions that were previously ignored. Specifically, the function returns -ENODEV when drm_dev_enter fails, indicating that the DRM device is not available or accessible for the requested operation. This prevents race conditions and use-after-free scenarios where code might attempt to access resources belonging to a device that has been removed or is being unloaded. Additionally, the validation logic now checks if the image size is zero or exceeds the one-megabyte limit of the PSP private buffer, returning -EINVAL in such cases. This strict boundary checking ensures that memory allocation and copy operations remain within safe limits, preventing potential buffer overflows or out-of-bounds writes into the fw_pri_buf structure.
The operational impact of this vulnerability was primarily related to system stability and security integrity during GPU initialization sequences. Without these checks, a malicious actor with local access could potentially supply crafted firmware images designed to trigger undefined behavior in the kernel space. While direct remote exploitation is unlikely due to the hardware-specific nature of AMDGPU drivers, local privilege escalation or denial-of-service attacks remain plausible risks if an attacker can influence the loading process through device nodes or configuration interfaces. The fix ensures that invalid inputs are rejected early in the pipeline, maintaining the integrity of the secure boot chain and preventing corruption of critical firmware structures managed by the PSP.
From a standards perspective, this remediation aligns with CWE-20 Improper Input Validation and CWE-119 Buffer Overflow beyond Restricted Memory Boundary. The implementation also reflects best practices for ATT&CK technique T1059 Command and Scripting Interpreter if one considers how kernel drivers interact with user-supplied data streams. By enforcing strict size limits and verifying device state, the driver adheres to secure coding principles that mitigate risks associated with untrusted input processing in privileged contexts.
To further enhance security posture, it is recommended that organizations ensure their Linux kernels are updated to include this patch. Administrators should also monitor for any unusual behavior during GPU initialization or firmware loading processes. Regular auditing of kernel logs can help detect attempts to load malformed firmware images before they cause system instability. Additionally, maintaining strict access controls on device nodes associated with AMD GPUs reduces the attack surface available to local users attempting to exploit driver vulnerabilities.