Look up another CVE · open CVE-2026-64097 in the interactive tracker
CVE-2026-64097
drm/amd/display: Validate GPIO pin LUT table size before iterating
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem drivers/gpu. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-64097 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixed | 6.1.176-1 | Update the kernel and reboot. Fixed in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
[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)
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
- What this is
- AMD DISPLAY COREMAINTAINERS section matched on drivers/gpu/drm/amd/display/ · amd-gfx@lists.freedesktop.org · Supported
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/gpu
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.15 | 6.1.175 | 9900f6954be7 |
| 4.15 | 6.6.142 | fb30a3890d62 |
| 4.15 | 6.12.92 | 67461e0c1533 |
| 4.15 | 6.18.34 | 7ca695b31222 |
| 4.15 | 7.0.11 | f2a4827e980b |
| 4.15 | 7.1 | 86d2b20644b1 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is reached only through the amdgpu DRM/display stack when the kernel parses VBIOS GPIO tables during connector/link setup (dc_create → link_create → get_gpio_i2c_info()/bios_parser_get_gpio_pin_info()); there is no network, Bluetooth, or USB packet path to this code.
- AC:LAttack complexity, low
- Once a GPU carries a VBIOS with an inflated gpio_pin_lut structuresize, the derived loop count is fully attacker-controlled and the out-of-bounds read triggers deterministically on driver probe or display link initialization without races or layout-dependent conditions.
- PR:LPrivileges required, low
- No capability checks guard the call path; any local user with ordinary access to the AMDGPU DRM device (typical video/render group membership) reaches the vulnerable parsers during normal display initialization, while a malicious VBIOS can be preinstalled via physical GPU reprogramming, supply-chain compromise, or prior privileged vbflash without ongoing root at trigger time.
- UI:NUser interaction, none
- Exploitation requires no victim interaction beyond system/driver startup; on laptops and servers with AMD GPUs the vulnerable parsing runs automatically during amdgpu module load and connector enumeration, including built-in eDP paths.
- S:UScope, unchanged
- Impact stays within kernel/GPU driver context on the same machine; corrupted VBIOS parsing does not cross a VM-host, container, or IOMMU security boundary even in SR-IOV or passthrough deployments.
- C:HConfidentiality impact, high
- The loop performs an out-of-bounds read past the validated GPIO pin LUT when structuresize overstates the table, potentially reading adjacent kernel heap memory beyond the kmalloc'd VBIOS image and feeding attacker-influenced bytes into subsequent GPIO register-index lookups.
- I:HIntegrity impact, high
- Mis-parsed out-of-bounds gpio_pin_assignment entries supply data_a_reg_index and gpio_bitshift values that drive MMIO/GPIO configuration (DDC, HPD, I2C pin setup), enabling arbitrary display-engine register targeting and memory-corruption-class integrity impact rather than a benign read-only fault.
- A:HAvailability impact, high
- Invalid register offsets and masks derived from out-of-bounds data can hang or fault the display subsystem and broader kernel (GPU reset, oops, or denial of service), and uncontrolled reads past the VBIOS buffer boundary can provoke crashes under memory-hardening or on marginal hardware.