CVE-2026-53138

What it actually does

This flaw is in the Linux kernel AMD display driver VBIOS parsing logic. During GPU probe or initialization, the driver walks VBIOS record chains and previously relied on a terminator record or zero record size to stop. A malformed VBIOS image without the expected terminator could cause unbounded iteration and, near the image boundary, out-of-bounds reads beyond the minimally validated record header. The practical impact is primarily denial of service through excessive CPU consumption, delayed or failed device initialization, boot instability, or kernel crash when an affected system parses a malicious or corrupted AMD GPU VBIOS image.

Why it matters to the business

The main risk is operational disruption on Linux systems using affected AMD GPU display drivers, especially workstations, graphics servers, VDI hosts, rendering systems, or appliances that depend on GPU initialization. Exploitation generally requires control over, or introduction of, a malformed GPU VBIOS image or malicious PCIe/GPU device, so broad internet-scale exploitation is unlikely. The issue is not in CISA KEV, is not known to be used in ransomware campaigns, and has a very low EPSS score, which makes emergency response less likely unless the organization allows untrusted hardware, firmware updates, GPU passthrough, or physical device access.

How an attack unfolds

An attacker first needs a way to make the target Linux kernel parse a malformed AMD GPU VBIOS image. Plausible paths include tampering with GPU firmware, supplying a malicious or compromised PCIe device, abusing an insecure firmware update process, or influencing a virtualized environment where a crafted GPU device or passthrough configuration is exposed to the guest. When the AMD display driver probes the device, it parses VBIOS record chains in bios_parser.c or bios_parser2.c. If the record chain omits the normal 0xFF terminator and avoids a zero record size, the vulnerable driver continues walking records far beyond the intended number of entries. This can consume substantial CPU during probe and may cause out-of-bounds reads near the end of the BIOS image. The likely result is a denial of service: boot delays, driver initialization failure, display/GPU unavailability, kernel warnings, or a crash.

How to fix it

Update the Linux kernel to a vendor-supported build that includes the fix for the AMD display VBIOS parser record-chain bounds checks, specifically the change that caps record-chain walks to BIOS_MAX_NUM_RECORD in drm/amd/display bios_parser.c and bios_parser2.c. No exact fixed package versions were provided in the input, so use the Linux distribution, appliance, or kernel vendor advisory as the source of truth for fixed kernel package versions. If immediate patching is not possible, reduce exposure by preventing untrusted PCIe/GPU hardware from being attached, restricting firmware update privileges, enabling Secure Boot and firmware integrity controls where available, using IOMMU/PCIe access controls, and avoiding passthrough of untrusted GPU devices to Linux guests. As an emergency availability mitigation on systems not requiring AMD display functionality, consider temporarily blacklisting the amdgpu driver, booting with reduced graphics initialization, or using vendor-supported kernel parameters, understanding this may disable GPU/display capabilities.

How to confirm the fix worked

Confirm the running kernel package or source tree includes the upstream fix that bounds AMD display VBIOS record-chain loops to 256 iterations. Check distribution changelogs, kernel package metadata, or source patches for references to the CVE, the AMD display VBIOS parser fix, BIOS_MAX_NUM_RECORD, or the upstream commit lineage. Identify exposed systems by checking for Linux hosts with AMD GPUs and the amdgpu driver loaded. Validate operationally by rebooting or reprobeing representative patched systems and confirming GPU initialization completes normally without excessive probe-time CPU usage, kernel warnings, or display driver failures. Avoid testing with malformed firmware on production systems; use controlled lab hardware or vendor-provided regression tests only.

Typical attack path

1. Obtain a path to influence GPU firmware, option ROM contents, a PCIe device presented to the host, or a virtualized GPU/device model.
2. Craft or introduce a malformed AMD GPU VBIOS image whose record chain is missing the expected terminating record and uses nonzero record sizes.
3. Trigger Linux boot, GPU hotplug, driver load, or device reprobe so the amdgpu display driver parses the malformed VBIOS.
4. The vulnerable parser enters excessive record-chain iteration and may read beyond the intended VBIOS structure boundary.
5. The system experiences degraded availability, failed GPU/display initialization, boot delays, kernel instability, or crash.

How to detect it

Look for evidence of abnormal AMD GPU probe or initialization behavior, especially after GPU replacement, firmware flashing, host reboot, hotplug events, or changes to device passthrough. Relevant sources include kernel logs, boot logs, hypervisor device assignment logs, firmware update records, endpoint management logs, and crash dump metadata. Search for repeated or prolonged amdgpu initialization messages, boot stalls around DRM or AMD display initialization, kernel watchdog events during GPU probe, out-of-bounds or memory-safety warnings involving drm/amd/display, and unexplained kernel panics after parsing VBIOS/ATOM BIOS data. Also investigate any unauthorized GPU firmware update activity, unexpected PCIe device inventory changes, or unapproved passthrough of GPU hardware to Linux guests. There are no reliable public, CVE-specific indicators of compromise for this issue; detection is primarily behavioral and forensic around firmware/device trust and kernel availability events.

What your security team should do

• Inventory Linux systems with AMD GPUs or amdgpu driver usage, prioritizing workstations, GPU compute/rendering hosts, VDI infrastructure, and systems that allow device passthrough or hardware changes.
• Patch affected systems through the operating system or kernel vendor once fixed packages are available; prioritize systems exposed to untrusted hardware, firmware update workflows, or multi-tenant virtualization.
• Restrict firmware flashing, PCIe device access, Thunderbolt/USB4 PCIe tunneling, and GPU passthrough to trusted administrators and trusted devices only.
• Monitor kernel and boot logs on AMD GPU systems for unusual GPU probe hangs, amdgpu initialization failures, or kernel crashes after hardware or firmware changes.
• If patching must be delayed, document compensating controls and consider disabling or blacklisting amdgpu on systems where GPU/display functionality is nonessential.
• Because EPSS is very low, exploit maturity is listed as none, and the issue is not in KEV, treat this as a targeted availability and hardware/firmware trust risk rather than an internet-exposed emergency.