CVE-2026-53135

What it actually does

This vulnerability affects the AMD display driver in the Linux kernel debugfs interface. The vulnerable function, dp_sdp_message_debugfs_write(), can dereference a NULL CRTC pointer when a DisplayPort connector is present but not currently bound to a CRTC, such as during hot-plug or before an atomic display commit. A write to the affected sdp_message debugfs node can therefore trigger a kernel NULL pointer dereference and crash the system. The same code path also ignores the user-supplied write length and attempts to copy a fixed 36 bytes from user space, which can read beyond the supplied user buffer when fewer than 36 bytes are provided. The practical impact is local denial of service through kernel panic or system instability; there is no indication from the available information that this enables remote code execution or privilege escalation.

Why it matters to the business

Systems using affected Linux kernel builds with AMD display hardware may be vulnerable to local crashes if debugfs is accessible and the affected debugfs node can be written. The most likely operational consequence is unplanned workstation, kiosk, appliance, or server downtime where graphical AMD display components are present. Because the vulnerability is not in the CISA Known Exploited Vulnerabilities catalog, has low EPSS, and has no reported exploit maturity, broad internet-scale exploitation is unlikely; however, shared systems, developer workstations, lab machines, GPU-enabled endpoints, and environments where users or automation have elevated local access should still treat it as a stability and availability risk.

How an attack unfolds

An attacker first needs local access to a Linux system running an affected kernel with the AMD display driver active and debugfs mounted. The attacker then identifies the relevant AMD DisplayPort SDP debugfs entry, typically under /sys/kernel/debug/dri/, and waits for or induces a display state where a connector is present but not bound to a CRTC, such as during or after a hot-plug event before the next atomic display commit. By writing crafted or short input to the sdp_message debugfs node, the attacker reaches dp_sdp_message_debugfs_write(). In vulnerable kernels, the function may dereference connector->base.state->crtc without validating that the state and CRTC pointers are non-NULL, causing a kernel oops or panic. Separately, a short write can cause the function to request more bytes from user space than were provided. The likely end result is a local denial-of-service condition requiring reboot or administrative recovery.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the AMD display debugfs SDP handling issue. The fix returns -ENODEV when connector state or CRTC is NULL and clamps the copy_from_user() length to the smaller of the supplied user size and the internal buffer size. Where exact distribution package versions are not provided, use the latest security kernel update from the operating system vendor and verify that the patch corresponding to upstream commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300 or its backport is included. If immediate patching is not possible, reduce exposure by disabling or unmounting debugfs where operationally feasible, restricting access to /sys/kernel/debug to trusted administrators only, avoiding unnecessary local user access on affected graphical systems, and limiting physical or scripted display hot-plug activity on sensitive systems until patched.

How to confirm the fix worked

Confirm remediation by checking that the running kernel includes the vendor security update or the backported fix for the AMD display sdp_message debugfs path. Validate that debugfs is either not mounted or is restricted to privileged users if it is required. On source-based or custom kernels, verify that dp_sdp_message_debugfs_write() checks connector->base.state and state->crtc before dereferencing and clamps the user write length instead of unconditionally copying 36 bytes. Operational validation can include confirming that writes to the affected sdp_message debugfs node return an error such as -ENODEV when no CRTC is bound instead of causing an oops or panic. Also review kernel logs after validation testing to ensure no NULL pointer dereference, amdgpu crash, or DRM-related kernel oops occurred.

Typical attack path

1. Gain local shell or code execution on a Linux system running an affected kernel with AMD display support.
2. Confirm debugfs is mounted and accessible, commonly at /sys/kernel/debug.
3. Locate AMD DRM debugfs entries under /sys/kernel/debug/dri/ that expose an sdp_message write interface.
4. Create or wait for a connector state where the connector is connected but not bound to a CRTC, for example around DisplayPort hot-plug activity before an atomic commit.
5. Write data, including a short buffer, to the affected sdp_message debugfs node.
6. Trigger the vulnerable kernel code path in dp_sdp_message_debugfs_write().
7. Cause a kernel NULL pointer dereference, oops, panic, or system hang, resulting in local denial of service.

How to detect it

To determine whether this was already exploited or triggered, review kernel and system logs for crashes involving the AMD display driver, DRM debugfs, or dp_sdp_message_debugfs_write(). Relevant log sources include dmesg output, systemd journal entries from the kernel facility, /var/log/kern.log, /var/log/messages, /var/log/syslog, persistent pstore/ramoops records, kdump/vmcore artifacts, and crash reporting systems such as ABRT or apport where deployed. Look for NULL pointer dereference, kernel oops, panic, general protection fault, or BUG messages with stack traces referencing amdgpu, drm, dp_sdp_message_debugfs_write, or sdp_message. Also review shell history, auditd logs, process accounting, and EDR telemetry for writes or redirections to /sys/kernel/debug/dri/*/sdp_message. Because exploitation requires local write access to debugfs, correlate suspected crash times with local user sessions, sudo activity, hot-plug/display events, and command execution touching debugfs paths. There are no known public malware-specific indicators from the provided information; detection should focus on crash signatures and access to the affected debugfs node.

• dp_sdp_message_debugfs_write
• sdp_message
• /sys/kernel/debug/dri/
• /sys/kernel/debug/dri/*/sdp_message
• NULL pointer dereference
• Oops:
• Kernel panic
• general protection fault
• BUG: kernel NULL pointer dereference
• amdgpu
• drm/amd/display
• copy_from_user
• connector->base.state->crtc
• echo * > /sys/kernel/debug/dri/*/sdp_message
• tee /sys/kernel/debug/dri/*/sdp_message

What your security team should do

• Prioritize patching Linux systems that use AMD GPUs or AMD display drivers, especially workstations, shared development machines, kiosks, and GPU-enabled endpoints.
• Inventory systems with debugfs mounted at /sys/kernel/debug and AMD DRM entries under /sys/kernel/debug/dri/.
• Apply the latest vendor-supported kernel update or verify inclusion of the upstream/backported fix for commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300.
• Restrict debugfs access to trusted administrators and unmount debugfs on production systems where it is not required.
• Review sudoers rules, automation, containers, and support tooling that may allow non-administrative users to write under /sys/kernel/debug.
• Monitor kernel logs for DRM, amdgpu, NULL pointer dereference, and dp_sdp_message_debugfs_write() crash signatures.
• Treat any unexplained reboot or kernel panic on AMD display systems with debugfs access as potentially relevant until logs are reviewed.