CVE-2026-53135: Linux AMD Display Driver Debugfs NULL Pointer and Buffer Over-Read

Technical summary

CVE-2026-53135 is a NULL pointer dereference and buffer over-read in the dp_sdp_message_debugfs_write() function within the AMD display subsystem of the Linux kernel. The function fails to validate that connector->base.state->crtc is non-NULL before dereferencing it, and ignores the user-supplied size parameter when calling copy_from_user(), hardcoding a 36-byte read instead. The fix involves adding NULL checks for both the connector state and CRTC pointer, returning -ENODEV when either is absent, and clamping the copy size to min(size, sizeof(data)). This patch was cherry-picked from upstream commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300.

Business impact

This vulnerability impacts availability on affected Linux systems running AMD-based graphics hardware with the debugfs interface enabled. An unprivileged local attacker can trigger a kernel panic, forcing a reboot and causing service disruption. The attack surface is limited to systems where debugfs is accessible (often restricted to root or specific user groups), but misconfigurations could widen exposure. Organizations relying on desktop or server environments with AMD GPUs and kernel debugging enabled should treat this as a denial-of-service risk.

Affected systems

The Linux kernel is the sole affected component. All kernel versions prior to the incorporation of the patch commit are vulnerable. The flaw exists specifically in the AMD display (amd/display) subsystem, affecting systems with AMD graphics hardware. Distributions shipping unpatched kernels with debugfs enabled are susceptible. The CVSS vector indicates local access is required; remote exploitation is not possible.

Exploitability

Exploitation requires local access to the affected system and the ability to write to the /sys/kernel/debug/dri/X/DP-Y/sdp_message debugfs node. Unprivileged users can typically interact with debugfs on development systems or misconfigured production machines. The attack is trivial—a single write to the debugfs file with specific input can trigger the crash. No special tools, knowledge of ASLR bypasses, or timing constraints are necessary. The vulnerability is not tracked as actively exploited in the wild (not on the CISA KEV list), but the low barrier to exploitation makes it a practical concern for vulnerable systems.

Remediation

Apply the kernel patch that adds NULL checks and input validation to dp_sdp_message_debugfs_write(). The fix is minimal and non-invasive, affecting only the debugfs code path. Organizations should verify the specific kernel version or patch identifier against their distribution's advisory. As an interim mitigation, restrict write access to debugfs by disabling it entirely (if debugging is not needed) or by tightening permissions on /sys/kernel/debug to exclude unprivileged users.

Patch guidance

Identify your Linux distribution and kernel version using `uname -r`. Consult your vendor's security advisory or kernel changelog to confirm whether your kernel includes commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300 or an equivalent fix. Most mainstream distributions (Red Hat, Ubuntu, Debian, SUSE) will push updates to their kernel repositories; apply the latest stable or long-term support kernel update available for your release. Test the patched kernel in a non-production environment first to ensure compatibility with your hardware and workload. Verify the patch by checking kernel module signatures or comparing source signatures post-update.

Detection guidance

Monitor system logs for kernel panic messages related to amd/display or debugfs writes, typically appearing in dmesg or /var/log/kern.log. Watch for repeated attempts to write to /sys/kernel/debug/dri/*/DP-*/sdp_message, which may indicate exploitation attempts. On vulnerable systems, enable kernel debugging (if safe) to capture more detailed stack traces. Use file integrity monitoring or audit rules (`auditctl -w /sys/kernel/debug/dri/ -p w`) to log any writes to the debugfs directory. Check whether your system has debugfs mounted and accessible to unprivileged users via `mount | grep debugfs` and `ls -la /sys/kernel/debug/`.

Why prioritize this

Although the CVSS score is medium (5.5), prioritization should be based on your environment's debugfs exposure. Systems with debugfs accessible to unprivileged users or those used for development are at higher risk. The fix is trivial and carries minimal regression risk, making early patching cost-effective. However, if debugfs is disabled or tightly restricted in your environment, this can be deprioritized below critical infrastructure updates. Factor in your AMD GPU adoption rate and kernel update cadence.

Risk score, explained

The CVSS 3.1 score of 5.5 (MEDIUM) reflects a high-impact but low-likelihood scenario: availability impact is severe (kernel crash), but the attack vector is strictly local and requires moderate privileges (debugfs write access). The lack of confidentiality or integrity impact, combined with the requirement for local access, prevents a higher score. The score appropriately weights this as a denial-of-service threat rather than an arbitrary code execution or privilege escalation vulnerability.

Frequently asked questions