CVE-2026-53137

What it actually does

This is a Linux kernel out-of-bounds write in the AMD display driver during HDMI HDCP 2.x repeater authentication. The driver trusts a 10-bit message size value reported by an HDMI sink/repeater and uses it as the read length for the HDCP ReceiverID list, even though the destination buffer is only 177 bytes. A malicious HDMI repeater can advertise an oversized ReceiverID list length, causing the kernel driver to write past the end of the buffer during an I2C read. The most likely technical outcome is kernel memory corruption leading to a crash or denial of service; in less likely conditions, depending on memory layout, hardening, and exploit reliability, kernel-level code execution may be theoretically possible.

Why it matters to the business

The practical risk is concentrated on systems with AMD graphics using HDMI HDCP 2.x where an attacker can physically connect or interpose a malicious HDMI device, repeater, capture device, dock, adapter, or KVM. Successful exploitation could crash affected Linux systems, interrupt displays, kiosks, workstations, media systems, or embedded devices, and potentially create a deeper compromise if kernel memory corruption is made reliable. EPSS is currently very low and there is no known CISA KEV listing or public exploit maturity, so broad internet-scale exploitation is unlikely; however, the kernel-level impact makes patching important for exposed physical-access or untrusted-peripheral scenarios.

How an attack unfolds

An attacker needs control of an HDMI device in the display chain, such as a malicious repeater, adapter, dock, KVM, capture device, or display emulator connected to a Linux system using the AMD display driver. When HDCP 2.x repeater authentication begins, the host reads the sink's RxStatus register. The malicious device reports an oversized ReceiverID list message size, up to the 10-bit field maximum of 1023 bytes. The vulnerable driver uses that attacker-controlled size as the I2C read length into a fixed 177-byte rx_id_list buffer. The read then writes beyond the buffer boundary in kernel memory, corrupting adjacent memory. Depending on timing and memory layout, this may immediately trigger a kernel oops, panic, GPU/display failure, or system reboot; a highly capable attacker could attempt to shape the corruption for more serious kernel compromise, though no mature exploit is currently reported.

How to fix it

Apply a Linux kernel update from the relevant distribution or device vendor that includes the AMD display driver fix to clamp the HDCP 2.x HDMI ReceiverID list read length to the rx_id_list buffer size. If a packaged fixed version is not available, track vendor kernel advisories for this issue or backport the upstream fix associated with the AMD display HDCP change in mod_hdcp_read_rx_id_list(). Where immediate patching is not possible, reduce exposure by avoiding untrusted HDMI repeaters, docks, adapters, KVMs, capture devices, and display emulators; prefer trusted direct display connections; disable HDCP/protected-content workflows where operationally acceptable; and restrict physical access to affected systems. Because this is kernel code, mitigation should be treated as incomplete until the affected kernel is replaced or patched.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor fix for this issue, not merely that a patched kernel is installed but not booted. On source-based or custom kernels, inspect the AMD display HDCP implementation and confirm that mod_hdcp_read_rx_id_list() clamps the HDMI HDCP2 ReceiverID list read length to the size of the rx_id_list buffer before the I2C read. Reboot into the fixed kernel and verify with uname/package-manager output. For exposure validation, identify Linux systems using AMDGPU/AMD display functionality with HDMI outputs and HDCP-capable workflows, especially systems connected through repeaters, docks, KVMs, adapters, or other untrusted HDMI intermediary devices. If available, run vendor or kernel self-tests and monitor dmesg/journal logs while connecting HDMI devices for absence of KASAN, kernel oops, amdgpu, HDCP, or I2C-related memory-corruption messages.

Typical attack path

1. Obtain or configure an HDMI sink/repeater-like device capable of influencing HDCP 2.x repeater authentication responses.
2. Connect the malicious HDMI device, or place it inline, between the target Linux system with AMD graphics and the display path.
3. Trigger HDMI HDCP 2.x repeater authentication, for example by connecting the display path or starting protected-content negotiation.
4. Return an RxStatus value indicating a ReceiverID list message size larger than the driver's 177-byte destination buffer.
5. Cause the AMD display driver to perform an oversized I2C read into rx_id_list.
6. Induce kernel memory corruption, resulting in a crash, display subsystem failure, reboot, or potentially further exploitation if the corruption can be controlled.

How to detect it

Historical exploitation detection is difficult because the triggering input comes from a physically connected HDMI device and may leave only kernel crash evidence. Review kernel logs, system journals, crash dumps, pstore records, netconsole output, and display/GPU service logs for events occurring immediately after HDMI hotplug, dock/KVM connection, display changes, or protected-content playback. Look for kernel oops, panic, KASAN, UBSAN, page fault, general protection fault, or slab/stack out-of-bounds messages involving the AMDGPU display stack, HDCP handling, HDMI, AUX/I2C/DDC reads, or the function mod_hdcp_read_rx_id_list(). In environments with physical-access monitoring, correlate suspicious display-device connection events with system crashes or GPU resets. If kernel crash dumps are available, inspect stack traces for AMD display HDCP functions and memory corruption near rx_id_list handling. Absence of logs does not prove absence of exploitation, especially if the system rebooted without persistent kernel logging.

• mod_hdcp_read_rx_id_list
• rx_id_list
• amdgpu
• drm/amd/display
• HDCP
• HDCP2
• HDMI
• I2C read
• KASAN: slab-out-of-bounds
• KASAN: stack-out-of-bounds
• BUG: KASAN
• kernel BUG
• general protection fault
• Oops:
• kernel panic
• amdgpu: GPU reset
• ReceiverID

What your security team should do

• Prioritize patching Linux systems with AMD graphics that are physically accessible to untrusted users or connected to untrusted HDMI devices, docks, KVMs, adapters, or capture equipment.
• Inventory Linux endpoints, kiosks, workstations, media systems, and embedded devices using AMDGPU/AMD display drivers and HDMI output paths.
• Ensure systems are rebooted into the fixed kernel after updates; kernel package installation alone is not sufficient.
• Until patched, prohibit or tightly control untrusted HDMI peripherals and inline display devices in sensitive environments.
• Monitor kernel logs for crashes or memory-corruption signatures involving amdgpu, HDCP, HDMI, I2C, or mod_hdcp_read_rx_id_list after HDMI device connection events.
• For custom kernels, backport the upstream clamp fix and rebuild rather than relying on configuration-only mitigations.
• Treat unexplained kernel panics or display-driver crashes following HDMI connection events as potential exploitation or fuzzing attempts and preserve logs for forensic review.