CVE-2026-64097 Fix: Update AMD Linux GPU Kernels

CVE-2026-64097 is a newly published Linux kernel vulnerability in AMD’s Display Core code that turns a seemingly routine firmware-parsing mistake into a potentially serious local security issue: a malformed or malicious AMD GPU VBIOS can cause the kernel to read beyond the mapped BIOS image while processing GPIO pin lookup-table entries. The upstream fix is compact—validate the full table size before iterating—but its importance is larger than its patch footprint suggests. It affects the kernel component that helps initialize display-related hardware behavior on AMD graphics systems, carries a kernel.org CVSS 3.1 score of 7.8 High, and has already been backported across several supported stable kernel branches. For Windows users, the immediate headline is more nuanced: this is not a vulnerability in the native Windows AMD graphics driver stack, but it matters to dual-boot users, Linux workstation fleets, GPU-enabled development environments, virtualized infrastructure, and organizations that use Linux on AMD-based client hardware.

---

Overview​

CVE-2026-64097 was published to the CVE List on July 19, 2026, and surfaced in the National Vulnerability Database shortly afterward. The flaw resides in drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c, within the Linux kernel’s AMD Display Core implementation. Specifically, the affected code parses a GPIO pin table stored in AMD video BIOS, or VBIOS, data.
The vulnerability exists because two parsing paths—get_gpio_i2c_info() and bios_parser_get_gpio_pin_info()—calculate how many GPIO table entries to inspect from a firmware-supplied structuresize field. Before the correction, the code established that the table header was present in the mapped firmware image but did not establish that the header’s claimed full table length was genuinely accessible.
That distinction is central. A table can contain a valid-looking header at a valid address while declaring a body that extends beyond the actual available firmware image. Once the parser trusts that oversized length and walks through the supposed GPIO pin entries, it can read memory outside the intended BIOS-image bounds.
Kernel.org assigned the issue a CVSS 3.1 vector of AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, or 7.8 High. The vector describes a local attack that requires low privileges and no user interaction, with potential impact to confidentiality, integrity, and availability. It does not mean every machine with an AMD GPU is remotely exploitable, nor does it automatically establish practical privilege escalation on every affected configuration. It does mean administrators should treat the update as a real kernel security remediation rather than as an inconsequential graphics compatibility patch.

The short version​

The technical and operational takeaway can be summarized in four points:

1. The issue is an out-of-bounds read in Linux AMD display firmware parsing.
2. The vulnerable code trusts a VBIOS table-size value without first validating that the claimed full range is mapped.
3. The upstream fix adds full-range validation before the iteration begins in both affected parser functions.
4. Supported stable Linux branches received fixes beginning with Linux 6.1.175, 6.6.142, 6.12.92, 6.18.34, and 7.0.11.

The vulnerability is especially notable because the dangerous input is firmware metadata, a category often treated as inherently trustworthy by low-level software. Modern platform security has repeatedly shown why that assumption deserves scrutiny.

---

Background​

AMD GPUs expose firmware data structures that the operating system uses to understand display hardware capabilities and wiring. In the Linux kernel, the Direct Rendering Manager, or DRM, subsystem provides the framework for graphics drivers, while AMD’s amdgpu driver and Display Core code handle many GPU-specific tasks, including display initialization, mode setting, connector management, power behavior, and communication with display-adjacent components.
VBIOS is not merely a relic of legacy PC boot flows. It remains an important source of configuration data for graphics hardware, especially where the operating system needs to know how physical display outputs, auxiliary controllers, sensors, buses, and power-management elements are arranged. The exact contents vary by board design, GPU generation, OEM implementation, and product category.
GPIO—general-purpose input/output—pins are flexible electrical interfaces used for low-level hardware signaling. In a GPU-display context, GPIO-related information can help the driver interact with features and components such as display buses, embedded controllers, board-level muxes, hot-plug-related logic, or I²C connections. A GPIO lookup table therefore is a small but meaningful piece of the system’s hardware description.

Why firmware parsing remains sensitive​

Firmware parsers occupy a difficult security boundary. The operating system needs firmware-provided data to configure hardware correctly, but that data is structurally complex and may not be perfectly formed. Hardware vendors, board partners, OEMs, system integrators, repair tooling, and attackers with sufficient local control can all influence the broader firmware ecosystem in different ways.
The secure-parser rule is simple: never infer that an internal length field is valid merely because the enclosing header exists. A parser must verify, at minimum, that:

• The starting offset is within the mapped image.
• The claimed length does not run past the image end.
• The length is large enough for the fixed header.
• Any iteration count derived from that length cannot exceed the accessible entry array.
• Arithmetic used for offsets, sizes, and counts cannot overflow.

CVE-2026-64097 concerns the second and fourth points. The original code had a partial validation step, but it was not strong enough to prove that every entry visited by the loop was legitimate to access.

---

The Vulnerability in Technical Terms​

The affected functions use the VBIOS table header’s structuresize field to determine how many GPIO pin records appear after the header. That is a conventional binary-format design: a header declares the overall structure length, and the parser subtracts the header size before dividing by the size of each entry.
Conceptually, the calculation looks like this:
entry_count = (structure_size - header_size) / gpio_pin_entry_size
The dangerous assumption is that structure_size accurately describes a region that is actually present in the BIOS image. If the data says “this table is 4 KB long,” but only a small header and a handful of bytes are available before the end of the mapped image, the arithmetic can still yield an entry count. A loop then follows that count into memory that is not part of the validated firmware table.

Header validation is not range validation​

The pre-fix behavior used a helper associated with obtaining the table image. The helper confirmed that the parser could access the header itself. That protects against a straightforward invalid offset where even the table header lies outside the mapped VBIOS region.
However, a valid header is only the beginning of a safe parse. The parser must also validate the entire byte range it intends to consume:
table_start + claimed_structure_size <= bios_image_end
Without that full-range check, the parser is effectively accepting an untrusted promise from firmware: “More entries exist here; please keep reading.” The vulnerability arises when that promise is false.

The corrected approach​

The fix calls bios_get_image() with the claimed full structuresize before either affected function begins to iterate over gpio_pin[] entries. In practical terms, the code now asks the BIOS-image accessor to validate that the complete VBIOS table range is available, not merely its initial header.
That is a good defensive design because it centralizes boundary checking in a helper built for BIOS-image access. It also makes the parser’s security condition explicit: the loop may proceed only after the full structure described by the firmware has been verified as accessible.
The change is small, but small validation additions are often exactly what separates robust binary parsing from memory-safety defects.

---

Why an Out-of-Bounds Read Can Matter​

An out-of-bounds read is sometimes incorrectly dismissed as less severe than an out-of-bounds write. Writes are often more directly associated with code execution or persistent memory corruption, but reads in kernel space can still be security-significant.
At a minimum, an invalid read can crash the kernel, producing a denial-of-service condition. Depending on the memory layout, fault behavior, subsequent code paths, and whether read values influence logic elsewhere, the consequences can extend beyond a simple system hang or reboot.

Confidentiality, integrity, and availability implications​

Kernel.org’s CVSS vector assigns high impact across all three traditional security properties:

• Confidentiality: An invalid read may expose kernel memory or firmware-adjacent data to later logic, diagnostics, logs, or interfaces, depending on the execution path.
• Integrity: Misread data can potentially influence decisions about hardware setup, GPIO routing, I²C behavior, or internal driver state.
• Availability: A read beyond mapped memory can trigger a fault, destabilize display initialization, crash the graphics stack, or panic the kernel.

The CVSS rating should be interpreted as a vendor assessment of potential impact rather than a guarantee of a universal exploit chain. No public exploit was identified in the published record, and the CVE description does not claim active exploitation. Still, local privilege requirements do not eliminate operational importance. On managed endpoints, developer workstations, shared lab systems, and multi-user Linux hosts, local attackers are often a realistic part of the threat model.

The role of attacker-controlled firmware​

A practical attack generally depends on an attacker being able to present malformed VBIOS data to the vulnerable kernel path. That is a significant condition and may require elevated access to reflash GPU firmware, physical access, a malicious device, a virtualized or emulated test arrangement, a compromised supply-chain component, or a system configuration that exposes firmware-like data in an unusual way.
This means CVE-2026-64097 should not be framed as “opening a malicious document compromises an AMD PC.” It is not that kind of bug. The vulnerability is more accurately understood as a low-level trust-boundary failure that may become relevant when an attacker can control or manipulate a graphics firmware input or can combine the flaw with another weakness.
That context matters for prioritization. It should be patched promptly, but incident responders should not assume that a normal desktop crash proves this CVE is being exploited.

---

Affected Linux Kernel Versions​

The published affected-version data indicates that the vulnerable logic existed in Linux starting from version 4.15 and remained present through multiple current stable branches until the relevant backports landed. The listed corrected stable releases are:

Stable kernel series	First listed fixed release
Linux 6.1 LTS	6.1.175
Linux 6.6 LTS	6.6.142
Linux 6.12 series	6.12.92
Linux 6.18 series	6.18.34
Linux 7.0 series	7.0.11
Mainline	7.1 and later

The practical rule is not to compare only the first two digits of a running kernel version. A system on 6.6.x, for example, is not necessarily protected merely because the 6.6 branch is supported. It must include the relevant stable patch level or an equivalent downstream vendor backport.

Distribution packaging changes the answer​

Linux distributions rarely expose vulnerability status solely through an upstream version number. Enterprise vendors and long-term-support distributions commonly backport targeted security patches without adopting a newer upstream kernel version. Conversely, a rolling distribution may move to a newer upstream version quickly but require a reboot before the updated kernel is actually running.
Administrators should use the distribution’s security advisory and package metadata as the authoritative source for a specific deployed system. The upstream fixed versions provide a useful baseline, but they do not replace vendor tracking.
A system can be protected in any of the following circumstances:

• It runs an upstream kernel at or beyond the corrected stable release for its branch.
• It runs a distribution kernel whose maintainer has backported the relevant patch.
• It runs a custom kernel that includes the upstream correction or an equivalent validation change.
• It does not use the vulnerable AMD Display Core code path because no relevant AMD display hardware or driver configuration is present.

The last item should be handled carefully. “Not expected to be reachable” is not the same as “patched.” For fleet compliance, a confirmed fixed package remains the cleanest answer.

Checking a local Linux host​

A straightforward first check is:
uname -r
That identifies the currently booted kernel. It does not reveal whether a downstream distributor backported the patch, so administrators should also inspect package changelogs or their vendor’s security portal.
For systems using a package manager, the workflow is generally:

1. Identify the running kernel and installed kernel packages.
2. Apply current security updates from the supported repository.
3. Confirm that the updated kernel package contains the vendor’s fix.
4. Reboot into the new kernel.
5. Run uname -r again and verify the expected version is active.

The reboot step is essential. Installing a fixed kernel while continuing to run the old one leaves the vulnerable code resident in memory.

---

AMD Display Core and the Broader Graphics Stack​

The affected file sits in the AMD display portion of the kernel graphics stack rather than in an application-level graphics API. That placement changes both the stakes and the remediation approach.
The Linux DRM subsystem handles kernel-mode graphics responsibilities. User-space components such as Mesa, Wayland compositors, X.Org, games, browsers, compute tools, and desktop environments depend on this foundational layer, but they do not replace it. If the kernel’s firmware parser makes an unsafe memory access during device setup or display initialization, updating a user-space graphics library will not remediate the underlying issue.

A display bug that is also a platform-security bug​

GPU firmware parsing may sound highly specialized, but it happens near the boundary where operating-system code interprets hardware-provided binary structures. That is a classic platform-security concern, alongside parsing ACPI tables, PCI option ROMs, storage-device metadata, USB descriptors, network adapter firmware interfaces, and UEFI-provided data.
The industry has steadily learned that peripheral and firmware-facing parsers need the same rigor as internet-facing protocol parsers. A malformed length field is not exotic. It is one of the oldest and most common sources of parser vulnerabilities because it can turn a small trust mistake into an invalid memory access.

Why the code has two affected paths​

The CVE description identifies both get_gpio_i2c_info() and bios_parser_get_gpio_pin_info(). That matters because a partial correction in only one of them would leave another route to the same flawed assumption.
When a parser format is shared across multiple routines, the security review must look for repeated patterns:

• Does each function validate the full table range?
• Does each function calculate entry counts safely?
• Do both functions reject tables smaller than their mandatory header?
• Are invalid firmware records handled consistently?
• Can later helper calls reintroduce unchecked offsets?

Fixing both named paths is therefore more than housekeeping. It closes two distinct opportunities for an oversized structuresize field to drive an unsafe iteration.

---

What This Means for Windows Users​

For a Windows-focused audience, the most important clarification is straightforward: CVE-2026-64097 targets Linux kernel code, not the AMD Windows display driver. A conventional Windows 10 or Windows 11 installation using AMD Software: Adrenalin Edition is not made vulnerable by this CVE merely because the machine contains a Radeon GPU.
The vulnerable source file belongs to the Linux kernel’s AMD DRM Display Core code. Windows uses a different kernel graphics-driver model and AMD’s separate Windows driver stack. Similar hardware does not imply shared operating-system driver code.

Dual-boot systems deserve attention​

The most obvious Windows-adjacent exposure is a dual-boot machine. Many enthusiasts use the same AMD desktop or laptop hardware for Windows gaming and Linux development, content creation, AI work, server tasks, or privacy-focused workflows.
On such a system, Windows may be unaffected while the Linux installation remains exposed until its kernel is updated. The right response is not to update AMD’s Windows driver in the hope that it solves the Linux issue. Update the Linux kernel through the relevant distribution channel and reboot into the patched kernel.

WSL is not a simple yes-or-no case​

Windows Subsystem for Linux adds nuance. Typical WSL 2 environments use a Microsoft-managed Linux kernel operating in a virtualized environment and expose accelerated graphics through a virtualization-oriented stack. They do not ordinarily use the guest’s native AMD Display Core driver to initialize the host’s physical Radeon display hardware in the way a bare-metal Linux installation does.
As a result, a standard WSL 2 installation is not expected to exercise the vulnerable bare-metal AMD VBIOS parsing path. That is not a blanket promise that every WSL-related configuration is immune. Users who run custom WSL kernels, unusual passthrough arrangements, nested virtualization, or specialized GPU testing environments should verify their configuration rather than rely on assumptions.

Windows administrators should avoid the wrong fix​

There are several unhelpful reactions to avoid:

• Do not treat this as a reason to uninstall or roll back the Windows AMD driver.
• Do not assume a Windows Update graphics package remediates a Linux kernel vulnerability.
• Do not ignore the issue if the same device also boots Linux from another partition, USB drive, or external SSD.
• Do not mistake an updated Linux kernel package for an active fix until the device has rebooted into it.

The correct remediation follows the operating system and kernel that actually contain the vulnerable code.

---

Enterprise Impact and Operational Priorities​

Enterprise Linux deployments should treat CVE-2026-64097 as a patch-management item with an additional hardware-inventory angle. The affected component is specific to AMD display code, but modern business fleets include more graphical Linux systems than many IT inventories acknowledge: engineering workstations, call-center thin clients, digital signage, kiosks, developer laptops, VDI hosts, edge appliances, laboratory systems, and media-production devices.
Servers without local AMD graphics or without the relevant AMD display driver may have lower practical exposure. Yet a uniform “servers are not graphical” assumption can fail in mixed-use estates, especially where GPU-equipped nodes support visualization, rendering, transcoding, machine learning, or remote desktop workloads.

Prioritizing the patch​

A sensible enterprise prioritization model should account for both vulnerability severity and exposure conditions:

1. Prioritize user-facing AMD Linux workstations and shared systems. These systems are more likely to initialize display hardware routinely and may have local users with varying trust levels.
2. Prioritize systems with custom firmware workflows. Labs that test VBIOS images, repair graphics hardware, perform board validation, or handle third-party GPU devices have a more direct relationship with the malformed-firmware scenario.
3. Review GPU-enabled development and virtualization hosts. Their actual exposure depends on physical-device usage and passthrough design, but they often have higher consequences if a host kernel becomes unstable.
4. Patch remaining affected devices through normal maintenance windows. Even where exploitability appears limited, the stable-kernel update is the appropriate long-term correction.

Availability matters even without exploitation​

For business systems, a display-driver crash can itself be damaging. Kiosk downtime, inaccessible remote desktops, failed conference-room displays, and disrupted visualization work are operational incidents, even if no data is stolen.
This is why kernel security fixes should not be evaluated solely through the lens of remote code execution. A local hardware-facing memory-safety issue can create reliability problems that are expensive in environments where uptime and predictable device behavior are essential.

Custom kernels require ownership​

Organizations compiling their own kernels must not wait for distribution packages that will never arrive. They should either move to a release containing the correction or manually backport the patch from the applicable stable branch.
The upstream patch was described as a cherry-pick from an earlier commit, which is common in Linux stable maintenance. That makes verification important: a custom vendor tree may have a differently named commit, a patch with altered context, or an equivalent correction integrated alongside other display changes. The key technical requirement is the behavior, not merely the presence of one particular commit identifier.

---

Strengths and Opportunities​

The response to CVE-2026-64097 contains several encouraging signs for Linux graphics security and for administrators maintaining mixed Windows-and-Linux fleets.

• The fix is narrowly scoped and easy to reason about. It validates the complete firmware table range before entry iteration, directly addressing the unsafe trust assumption.
• Multiple supported stable branches have received backports. That reduces pressure to abandon long-term-support kernels solely to obtain the remedy.
• The security condition is explicit. A future reviewer can see that parsing is conditioned on a successful full-size bios_get_image() check.
• The bug report identifies both affected parsing functions. Addressing both get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() avoids an incomplete one-path repair.
• The issue reinforces reusable secure-coding lessons. Firmware parsers, device drivers, and binary-format handlers can apply the same full-range-validation pattern.
• Windows-focused IT teams can use the disclosure to improve cross-platform asset awareness. A device’s exposure can differ substantially between native Windows, bare-metal Linux, WSL, virtual machines, and dual-boot configurations.

A useful audit pattern​

This CVE offers a practical code-review question for kernel and driver developers: whenever a loop count comes from a binary structure’s length field, what exact validation proves every loop iteration remains inside the mapped object?
That question should lead reviewers to check for:

• A range check covering the entire claimed structure.
• Safe subtraction before calculating entry counts.
• Rejection of undersized structures.
• Integer-overflow protections in size and offset calculations.
• Clear error paths when firmware data is inconsistent.

This style of audit can uncover related bugs even when no CVE has yet been reported.

---

Risks and Concerns​

The immediate patch is clear, but the broader situation still contains risks that administrators and developers should consider.

• The vulnerability is locally exploitable, not automatically harmless. Local access is a meaningful prerequisite, but it does not eliminate risk on shared, managed, or developer-oriented systems.
• Firmware is often treated as trusted too readily. The core failure demonstrates why platform firmware must be treated as structured external input.
• Downstream status can be difficult to assess. Kernel version strings alone may not reveal whether a distributor backported the correction.
• Reboots create a common remediation gap. A patched package does not protect a system that continues running an older kernel image.
• Custom and embedded deployments may lag. Appliance vendors, industrial systems, and self-maintained kernels often take longer to absorb stable updates.
• A narrow patch does not prove the entire parser is free of related flaws. Other VBIOS structures and drivers may contain similar patterns where headers are checked but variable-length bodies are not.

The CVSS caveat​

The 7.8 High score is appropriate for signaling urgency, yet it should not erase the environmental prerequisites. There is no public claim in the CVE record that the issue is being exploited in the wild, and the published description does not provide a working exploit chain.
Security teams should avoid two opposite mistakes: underreacting because the flaw is “only” an out-of-bounds read, or overreacting by classifying every Radeon-equipped Windows PC as compromised. The right stance is disciplined patching informed by the actual operating system, driver path, and hardware configuration.

---

Looking Ahead​

The next developments to watch are distribution advisories, downstream kernel package updates, and any additional technical analysis that clarifies exploitability under real hardware conditions. Because the NVD entry was recently published and had not yet received a NIST CVSS assessment at publication time, metadata may continue to evolve as enrichment proceeds.
Linux vendors will likely publish their own affected-package guidance on different schedules. Some will identify fixed kernel builds rapidly; others may roll the correction into broader maintenance updates. Organizations should track their vendor channel rather than attempting to map every internal device directly to upstream Git history.

What administrators should do now​

For teams responsible for AMD-based Linux systems, the near-term action list is uncomplicated:

1. Inventory Linux devices with AMD GPUs or AMD integrated graphics.
2. Identify the running kernel, not just the installed package version.
3. Apply vendor security updates that include the correction for CVE-2026-64097.
4. Reboot systems into the patched kernel during an appropriate maintenance window.
5. Document exceptions for custom, embedded, offline, or vendor-managed kernels.
6. Review VBIOS-flashing and GPU-firmware test procedures, particularly on shared or privileged systems.
7. Separate native Windows exposure from Linux exposure in communications to avoid inaccurate remediation guidance.

For home users, the process is simpler: update the Linux installation through its normal package manager or graphical software updater, reboot, and confirm the new kernel is active. Dual-boot users should apply that fix within Linux; Windows updates and AMD Windows graphics-driver updates address a different software stack.
CVE-2026-64097 is a reminder that graphics security is not confined to browsers, games, and user-space APIs. Deep beneath the desktop, drivers routinely interpret firmware structures that describe real hardware, and a single unchecked length field can cross the line from ordinary parsing into kernel memory-safety risk. The correction is already available across key Linux stable branches, making this a case where prompt, methodical patching is both practical and worthwhile—especially for the growing number of systems that move fluidly between Windows and Linux environments.

---

References​

1. Primary source: NVD / Linux Kernel
   Published: 2026-07-21T01:02:50-07:00
   
   

   NVD - CVE-2026-64097

   nvd.nist.gov
2. Security advisory: MSRC
   Published: 2026-07-21T01:02:50-07:00
   Original feed URL
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com