CVE-2026-53330

What it actually does

This is an out-of-bounds read in the Linux kernel AMD Display Core driver. The affected code processes DisplayPort link-training/tunable PHY repeater information and can index one element past the end of the aux_rd_interval array when a DisplayPort sink reports the maximum valid LTTPR repeater count. Because the flaw is in kernel-space display driver code, the most likely technical outcomes are kernel memory disclosure to adjacent logic, undefined behavior, GPU/display instability, or a kernel crash. The issue requires interaction with the affected AMD display stack and malformed or edge-case DisplayPort/DPCD data, so exploitation is most plausibly local/physical or via a malicious or compromised attached DisplayPort device rather than remotely over the network.

Why it matters to the business

Organizations using Linux systems with AMD graphics and DisplayPort-connected displays, docks, adapters, or repeaters could experience workstation or kiosk instability, display failures, or system crashes if exposed to a malicious or nonconforming DisplayPort device. The current exploitation signal is low: EPSS is 0.00124, it is not listed in CISA KEV, it is not identified as ransomware-related, and no mature public exploit is indicated. Operational priority should still be given to fleets where Linux AMD graphics systems are physically accessible to untrusted users, used in shared spaces, or depend on stable display output for business operations.

How an attack unfolds

An attacker would need a way to influence DisplayPort DPCD/LTTPR capability data presented to a vulnerable Linux system using the AMD display driver. This could be done with a malicious DisplayPort sink, emulator, adapter, dock, or repeater chain that reports 8 LTTPR repeaters. During DisplayPort link training or hotplug handling, the AMD display driver calls dp_get_eq_aux_rd_interval() with an offset that can reach the maximum repeater count. The vulnerable implementation reads aux_rd_interval[7] even though the array was only sized for indexes 0 through 6. The resulting out-of-bounds read occurs in kernel context and may cause a crash, instability, or exposure of adjacent kernel memory depending on build configuration, memory layout, and surrounding code behavior. There is currently no indication of broad in-the-wild exploitation or a weaponized exploit.

How to fix it

Upgrade to a Linux kernel build from the distribution or vendor that includes the upstream AMD display fix from commit a55a458a8df37a65ffda5cf721d554a8f74f6b04 or an equivalent backport. The fix increases aux_rd_interval to support the full MAX_REPEATER_CNT range. Because no exact affected product or fixed package versions were provided, use the kernel advisory from the relevant Linux distribution, hardware vendor, or appliance vendor to identify the corrected kernel package. Where immediate patching is not possible, reduce exposure by avoiding untrusted DisplayPort peripherals, docks, adapters, KVMs, and display emulators; prefer known-good hardware; restrict physical access to systems; and consider alternate display paths until the kernel can be updated.

How to confirm the fix worked

Confirm that systems are running a kernel package that contains the AMD display fix or vendor backport. Validate through distribution package changelogs, kernel source patches, or vendor security advisories referencing the AMD Display Core aux_rd_interval/MAX_REPEATER_CNT fix or commit a55a458a8df37a65ffda5cf721d554a8f74f6b04. On source-based or custom kernels, verify that struct dc_lttpr_caps defines aux_rd_interval with MAX_REPEATER_CNT elements rather than MAX_REPEATER_CNT - 1. After updating, reboot into the corrected kernel and confirm the active kernel version with standard system tooling. For exposure checks, inventory Linux systems using AMDGPU DRM display drivers and DisplayPort-connected hardware, especially systems with docks, repeaters, KVMs, or display emulators.

Typical attack path

1. Identify a Linux system using the AMDGPU DRM display stack with DisplayPort output exposed to a device the attacker can control.
2. Connect or interpose a malicious DisplayPort sink, dock, adapter, repeater, or protocol emulator capable of manipulating DPCD/LTTPR capability responses.
3. Report the maximum LTTPR repeater count so the driver processes an offset value that reaches the vulnerable boundary condition.
4. Trigger DisplayPort hotplug, link training, or display initialization so the kernel calls the affected AMD display helper routine.
5. Cause an out-of-bounds kernel read, potentially resulting in display failure, kernel warning, denial of service, or limited memory disclosure depending on runtime conditions.

How to detect it

Retrospective detection should focus on kernel, system, and crash logs because exploitation would occur inside the display driver during DisplayPort initialization or hotplug handling. Review journalctl, dmesg, syslog/kern.log, crash dumps, pstore, apport/ABRT reports, KASAN reports, and endpoint telemetry for AMDGPU/DRM errors near display hotplug events. Look for kernel oopses, panics, GPU resets, or sanitizer findings involving dp_get_eq_aux_rd_interval(), aux_rd_interval, dc_lttpr_caps, LTTPR, DPCD, or DisplayPort link training. Correlate suspicious events with physical access logs, newly introduced DisplayPort docks/adapters/KVMs, display emulators, lab hardware, or repeated connect/disconnect activity. Absence of these logs does not prove non-exploitation, because a non-instrumented kernel may only show a generic crash or display failure.

• dp_get_eq_aux_rd_interval
• aux_rd_interval
• dc_lttpr_caps
• MAX_REPEATER_CNT
• LTTPR
• DPCD
• amdgpu
• drm/amd/display
• BUG: KASAN: global-out-of-bounds
• global-out-of-bounds in dp_get_eq_aux_rd_interval
• kernel BUG at drivers/gpu/drm/amd/display
• Oops:
• Call Trace:
• amdgpu_dm
• DisplayPort link training
• link training failed
• AUX read
• drm:amdgpu

What your security team should do

• Prioritize patching Linux endpoints, workstations, kiosks, and appliances that use AMD graphics with DisplayPort in physically accessible or shared environments.
• Inventory systems loading the amdgpu kernel driver and using DisplayPort-connected displays, docks, adapters, KVMs, or repeaters.
• Apply the vendor-provided kernel update containing the AMD display aux_rd_interval/MAX_REPEATER_CNT fix, then reboot to ensure the fixed kernel is active.
• If patching is delayed, restrict untrusted physical access and avoid unknown DisplayPort peripherals or protocol-emulating devices.
• Monitor kernel logs for AMDGPU, DRM, DisplayPort link-training errors, KASAN out-of-bounds reports, kernel oops messages, or crashes following display hotplug events.
• Treat repeated crashes or KASAN findings involving dp_get_eq_aux_rd_interval() as suspicious when correlated with newly attached or unfamiliar display hardware.