CVE-2026-53136

What it actually does

This vulnerability is a heap out-of-bounds write in the Linux kernel AMD display driver during driver initialization. The driver reads HDMI retimer register counts from AMD VBIOS integrated information tables and uses those counts as loop bounds when copying register settings into fixed-size arrays. A malformed VBIOS can provide values larger than the destination arrays, causing memory corruption during AMD GPU display driver probe. The most likely technical outcomes are kernel crash, denial of service, or potentially local privilege escalation if an attacker can cause the system to load attacker-controlled GPU firmware, VBIOS data, or a malicious device/option ROM.

Why it matters to the business

Systems using affected Linux kernels with AMD graphics hardware may be vulnerable to crashes or deeper compromise if exposed to malicious or tampered GPU firmware or hardware. The practical exploitation bar is relatively high because the flaw depends on malformed VBIOS data and there is currently no known public exploitation, low EPSS, and no CISA KEV listing. Even so, kernel memory corruption should be treated seriously for workstations, graphics servers, virtualization hosts with GPU passthrough, and environments where physical access, untrusted peripherals, firmware supply-chain risk, or device assignment is in scope.

How an attack unfolds

An attacker first needs a way to influence the VBIOS data consumed by the AMD display driver, such as by tampering with GPU firmware, introducing a malicious or modified GPU/device, abusing a firmware update path, or influencing a virtualized GPU/PCI device model where VBIOS data is supplied to a guest. When the Linux system boots or the amdgpu display driver probes the device, the driver parses the integrated information table. The malformed table supplies excessive HdmiRegNum or Hdmi6GRegNum values. Vulnerable driver code then copies more HDMI retimer register entries than the fixed-size destination arrays can hold, corrupting adjacent heap memory in kernel context. Depending on memory layout and exploit reliability, this can result in a kernel panic, driver failure, display subsystem instability, or potentially controlled kernel memory corruption that could be developed into privilege escalation.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix which clamps HDMI retimer register counts to the destination array sizes before copying. If using a vendor-supported distribution kernel, apply the relevant security update from the distribution or hardware platform vendor rather than relying only on upstream version numbers. Where immediate patching is not possible, reduce exposure by restricting firmware update permissions, enforcing Secure Boot and firmware integrity controls where available, preventing use of untrusted GPUs or PCIe devices, limiting physical access, and carefully controlling GPU passthrough or assignment to virtual machines. Systems without AMD display hardware or without the affected amdgpu display code path are unlikely to be exposed.

How to confirm the fix worked

Confirm that the running kernel includes the fix for the AMD display driver retimer register count clamping logic. Validate through distribution advisory mapping, kernel changelog review, or source/package inspection for the relevant drm/amd/display changes that clamp HdmiRegNum and Hdmi6GRegNum with destination array bounds. Reboot into the updated kernel and verify with uname and package manager inventory that the patched kernel is active, not merely installed. On representative AMD GPU systems, confirm that the amdgpu driver loads successfully and that boot logs do not show driver probe failures, kernel warnings, memory corruption diagnostics, or GPU initialization crashes.

Typical attack path

1. Gain the ability to provide or modify AMD GPU VBIOS data, for example through firmware tampering, malicious hardware, compromised firmware update process, or controlled virtual GPU/device presentation.
2. Craft malformed VBIOS integrated information tables with HdmiRegNum or Hdmi6GRegNum values larger than the destination array sizes.
3. Cause a vulnerable Linux kernel to initialize or reprobe the affected AMD display driver against the malformed VBIOS.
4. Trigger the unchecked copy loop during get_integrated_info_v11() or get_integrated_info_v2_1() processing.
5. Achieve kernel heap memory corruption, leading to denial of service or, with further exploit development, possible kernel-level code execution or privilege escalation.

How to detect it

Look for evidence that a system parsed malformed AMD GPU VBIOS data or experienced memory corruption during amdgpu driver initialization. Useful sources include kernel ring buffer logs, persistent system journal entries, crash dumps, pstore/ramoops records, kdump vmcores, firmware update logs, hardware inventory changes, and hypervisor logs for GPU passthrough or virtual PCI device assignment. Search for amdgpu driver probe failures, VBIOS parsing anomalies, kernel heap corruption messages, KASAN/slab out-of-bounds reports, general protection faults, kernel panics, and repeated crashes during boot or GPU initialization. Because there are no public exploit-specific indicators and exploitation depends on malformed firmware/device data, detection should focus on suspicious firmware changes, unexpected GPU hardware identifiers, failed or unauthorized firmware flashes, and crash artifacts temporally associated with amdgpu initialization.

• amdgpu
• drm/amd/display
• VBIOS
• ATOM BIOS
• integrated info
• HdmiRegNum
• Hdmi6GRegNum
• get_integrated_info_v11
• get_integrated_info_v2_1
• kernel BUG
• kernel panic
• general protection fault
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• slab-out-of-bounds
• heap out-of-bounds
• Out of bounds memory access
• amdgpu: probe of
• amdgpu: VBIOS
• amdgpu: ATOM BIOS
• drm:amdgpu
• /sys/kernel/debug/dri/
• /var/crash/
• /sys/fs/pstore/

What your security team should do

• Prioritize patching Linux workstations, graphics servers, virtualization hosts, and systems using AMD GPUs, especially where GPU passthrough, physical access risk, or firmware supply-chain exposure exists.
• Verify whether fleet kernels are vendor-patched even if upstream version strings appear older, because Linux distributions frequently backport kernel security fixes.
• Audit firmware management controls for GPUs and related PCIe devices; restrict firmware flashing to trusted administrators and signed update channels.
• Review virtualization configurations that expose physical or emulated AMD GPU devices to guests and ensure host and guest kernels are updated where applicable.
• Monitor kernel logs for amdgpu probe failures, kernel panics, slab corruption, KASAN reports, or anomalous GPU initialization events that could indicate malformed VBIOS parsing.
• Treat unexpected GPU firmware changes, newly introduced PCIe graphics devices, or unexplained display-driver crashes as potential security events until validated.