Linux Kernel CVE-2026-53330

Requires an AMD GPU using the amdgpu DisplayPort path plus a downstream DisplayPort sink that reports the maximum of 8 LTTPR repeaters via DPCD - the offset value of 8 (MAX_REPEATER_CNT) is exactly what indexes aux_rd_interval[7] out of bounds. Exploitation is thus gated on: physically/locally attaching an attacker-influenced DisplayPort device (or otherwise controlling the DPCD repeater count), an unpatched kernel prior to 6.18.36/7.0.13/7.1, and AMD display hardware. Limiting factors: it is not remotely reachable over a network, it does not fire against default configurations without a malicious/crafted sink present, and it is confined to AMD-GPU DisplayPort deployments - sinks reporting the normal 0-7 repeater counts never reach the vulnerable index.

The signals point to a low-to-moderate real-world priority despite the 7.1 CVSS. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) indicates local access with low privileges and no user interaction, but the C:H/A:H impact ratings look generous for a single-element over-read that stays within the surrounding struct memory: the over-read value is a timing/AUX-read-interval byte, not attacker-exfiltrated data, so genuine confidentiality and availability impact appear limited. EPSS is low (0.17%, 6th percentile) and there is no KEV listing and no public exploit, consistent with a hard-to-weaponize local memory-safety bug. A notable nuance: the trigger is a DPCD value from a DisplayPort sink, meaning the practical 'attacker' may be a malicious or crafted display device rather than a local software user - this makes the AV:L/PR:L characterization defensible but worth verifying against your threat model. Overall: patch in the normal kernel-update cadence rather than as an emergency.

An attacker connects a crafted or emulated DisplayPort sink (monitor, dock, or MST hub) that advertises 8 LTTPR repeaters in its DPCD registers to a target machine with an AMD GPU; during link training the kernel calls dp_get_eq_aux_rd_interval() with offset 8 and reads one element past aux_rd_interval[], producing an out-of-bounds read. No public exploit exists, and given AV:L/AC:L the practical result is limited memory misread rather than reliable data exfiltration or code execution.