CVE-2026-64097

What it actually does

This flaw is an out-of-bounds read in the Linux kernel AMD display driver VBIOS parsing logic. The affected functions derive the number of GPIO pin entries from a VBIOS table structure size and then iterate over that table without first confirming that the full claimed table size is actually present in the mapped BIOS image. A malformed or corrupted VBIOS table can therefore cause the kernel driver to read beyond the end of the BIOS image while parsing AMD display GPIO/I2C information. The most likely technical outcomes are kernel memory disclosure to a local attacker, kernel fault, display-driver instability, or system crash. Because this occurs in kernel-space driver code, successful exploitation may also help defeat memory isolation or support follow-on local privilege-escalation research, although the described bug is specifically an out-of-bounds read.

Why it matters to the business

Systems using affected Linux kernels with AMD GPU display support may be exposed to local attacks that can crash endpoints or servers, leak sensitive kernel memory, or destabilize graphical and GPU-dependent workloads. The risk is highest on workstations, GPU-enabled servers, virtualization hosts using GPU passthrough, and systems where untrusted users or workloads can interact with local GPU hardware. The CVSS score indicates high severity, but the currently reported EPSS is low and there is no known CISA KEV listing or public exploit maturity, so remediation should be prioritized through normal kernel patch cycles unless the environment has high local multi-user exposure or untrusted hardware/pass-through scenarios.

How an attack unfolds

An attacker first needs local access or another path to cause the Linux AMD display driver to parse a malformed AMD VBIOS image or table. The attacker supplies or influences a VBIOS GPIO pin table whose header reports a structure size larger than the actually mapped BIOS image data. When the amdgpu display code initializes or queries GPIO/I2C pin information, the vulnerable parser trusts the claimed structure size, calculates too many gpio_pin entries, and iterates past the valid image boundary. The resulting out-of-bounds read occurs in kernel context. Depending on memory layout and error handling, this may expose adjacent kernel or firmware memory, trigger a kernel oops, crash the system, or provide information useful for chaining with another local kernel exploit. There are no named threat actors or known ransomware campaigns associated with this issue based on the supplied data.

How to fix it

Upgrade to a Linux kernel version or distribution kernel package that includes the AMD display driver fix for commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3 or an equivalent backport. The corrected code validates that the full claimed VBIOS table structure size is accessible before iterating over GPIO pin entries. Because exact fixed package versions were not provided, use the relevant Linux distribution security advisory, kernel changelog, or vendor errata to identify the fixed build for each supported release stream. Where immediate patching is not possible, reduce exposure by avoiding untrusted or externally supplied GPUs/option ROMs, restricting GPU passthrough to trusted devices only, limiting local shell access on GPU-enabled systems, enabling Secure Boot and kernel lockdown where operationally feasible, and disabling or avoiding the affected AMD display driver on systems that do not require it.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package is at or above the vendor-fixed version and that its changelog or source includes the AMD display patch that validates the full VBIOS table size using bios_get_image() before iterating in get_gpio_i2c_info() and bios_parser_get_gpio_pin_info(). On source-based or custom kernels, review the drm/amd/display BIOS parser code and confirm that the claimed table_header.structuresize is bounds-checked against the BIOS image before gpio_pin[] iteration. After upgrading, reboot into the fixed kernel and confirm with uname -a and package-manager queries that the patched kernel is active. For exposure validation, inventory Linux systems with AMD GPUs or loaded amdgpu modules, then prioritize those running affected kernel builds, especially multi-user systems and hosts using GPU passthrough.

Typical attack path

1. Obtain local access to a Linux system that uses the vulnerable AMD display driver code path.
2. Introduce or influence a malformed AMD VBIOS image or option ROM data, such as through malicious hardware, compromised firmware, a virtualized/passthrough GPU scenario, or another local mechanism that affects what the driver parses.
3. Trigger AMD display driver initialization or a code path that calls the GPIO/I2C VBIOS parsing functions.
4. Cause the parser to trust an oversized VBIOS table structure size and iterate beyond the actual mapped BIOS image.
5. Use the resulting out-of-bounds read to leak kernel-adjacent data, cause a kernel fault, or support follow-on local exploitation.

How to detect it

Look for evidence of prior exploitation or attempted triggering in kernel logs, boot logs, crash dumps, and endpoint telemetry from Linux systems using AMD GPUs. Relevant log sources include journalctl/kern.log, dmesg output, /var/log/syslog, /var/log/messages, kernel crash dump directories such as /var/crash, kdump/vmcore artifacts, and EDR telemetry for kernel oops or panic events. Focus on events involving amdgpu, drm/amd/display, VBIOS/ATOM BIOS parsing, GPIO pin table parsing, or crashes during GPU initialization, display detection, suspend/resume, boot, or VM GPU passthrough attachment. Signs of exploitation are likely to be indirect: kernel oopses, page faults, general protection faults, panics, or repeated GPU driver resets near calls to get_gpio_i2c_info() or bios_parser_get_gpio_pin_info(). Also review recent changes involving GPU firmware, option ROMs, PCI passthrough devices, hypervisor configurations, or newly attached AMD GPUs. Absence of these artifacts does not prove non-exploitation because an out-of-bounds read may not always crash or log a distinctive event.

• amdgpu
• drm/amd/display
• get_gpio_i2c_info
• bios_parser_get_gpio_pin_info
• gpio_pin
• VBIOS
• ATOM BIOS
• BUG: unable to handle kernel paging request
• general protection fault
• kernel NULL pointer dereference
• Oops:
• Kernel panic
• GPU fault detected
• amdgpu: failed to parse
• amdgpu: ATOM BIOS
• /var/crash
• /proc/modules
• /sys/module/amdgpu

What your security team should do

• Inventory Linux systems with AMD GPUs, loaded amdgpu modules, graphical workloads, or GPU passthrough configurations.
• Map each system to its running kernel version and applicable distribution security advisory, then identify whether the AMD display VBIOS bounds-check fix is present.
• Patch affected systems through the normal kernel update process, prioritizing multi-user hosts, virtualization hosts, developer workstations, and GPU-enabled servers handling sensitive workloads.
• Reboot systems after patching and verify they are running the fixed kernel rather than only having the package installed.
• Restrict local access to GPU-enabled systems until patched, especially where untrusted users, containers, or virtual machines can interact with GPU devices.
• Avoid passing through untrusted GPUs or option ROMs to production hosts or guests, and review virtualization policies for GPU passthrough exposure.
• Monitor kernel logs for amdgpu, drm/amd/display, VBIOS parsing errors, kernel oopses, or crashes around display-driver initialization.
• If suspicious crashes are observed, preserve kernel logs, crash dumps, loaded module lists, kernel version details, and hardware/firmware inventory for forensic review.