CVE-2026-53313

What it actually does

This is a Linux kernel NULL pointer dereference in the AMD display driver code path for DMUB service error handling. In dc_dmub_srv_log_diagnostic_data() and dc_dmub_srv_enable_dpia_trace(), the code attempts to log an error after determining that dc_dmub_srv may be NULL; because the logging macro uses dc_dmub_srv->ctx internally, a NULL dc_dmub_srv pointer can be dereferenced and trigger a kernel crash. The expected impact is local denial of service through a kernel oops or panic if an affected AMD display driver code path can be reached.

Why it matters to the business

Successful exploitation can crash affected Linux systems using vulnerable AMD display driver code, causing service interruption, workstation instability, failed graphical sessions, or downtime for systems that depend on AMD GPU/display functionality. The vulnerability is not currently listed in CISA KEV, has very low EPSS likelihood, no known mature exploit, and no ransomware association, so it should generally be prioritized behind actively exploited remote vulnerabilities unless the organization operates critical Linux systems with AMD graphics where availability is important.

How an attack unfolds

An attacker would need a way to cause the affected AMD display driver functions to be invoked with a NULL dc_dmub_srv value or to trigger the relevant error path during AMD display/DMUB handling. When the vulnerable path is reached, the driver attempts to emit an error message using DC_LOG_ERROR(). Instead of safely returning, the logging macro references dc_dmub_srv->ctx, dereferencing a NULL pointer in kernel context. This can result in a kernel oops, panic, display subsystem failure, or full system crash. There is no indication from the supplied data of remote exploitation, privilege escalation, data theft, public exploit code, ransomware use, or active exploitation by named threat actors.

How to fix it

Update to a Linux kernel version that includes the upstream fix for the AMD display driver NULL dereference in dc_dmub_srv_log_diagnostic_data() and dc_dmub_srv_enable_dpia_trace(). Where vendor kernels are used, apply the distribution or appliance vendor’s kernel update that backports this fix. If immediate patching is not possible, reduce exposure by limiting untrusted local access to affected systems, disabling or avoiding vulnerable AMD display driver paths where operationally feasible, using stable vendor-supported kernels, and ensuring kernel panic/reboot behavior is configured to recover systems after crashes. No exact affected product list or fixed version list was provided, so remediation should be validated against the relevant Linux distribution, hardware vendor, or kernel maintainers’ advisories.

How to confirm the fix worked

Confirm the running kernel includes the patch that separates the dc_dmub_srv NULL check from the dc_dmub_srv->dmub check and returns immediately when dc_dmub_srv is NULL before invoking DC_LOG_ERROR(). Validate by checking the installed kernel package changelog or source tree for the corrected logic in drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c. On Linux distributions, verify that the kernel package version is at or above the vendor-advised fixed build and reboot into that kernel. Exposure is most relevant on systems with AMD display driver support enabled; confirm loaded modules and hardware presence using standard Linux inventory methods such as lspci and lsmod. After updating, monitor dmesg/journal logs for absence of related kernel oops, NULL pointer dereference, or AMDGPU/DC/DMUB crash messages during display operations.

Typical attack path

1. Identify a Linux system running an affected kernel with AMD display driver support enabled.
2. Obtain local access or another mechanism capable of exercising AMD display/DMUB-related driver paths.
3. Trigger the vulnerable diagnostic logging or DPIA trace enablement error path where dc_dmub_srv is NULL.
4. Cause DC_LOG_ERROR() to dereference dc_dmub_srv->ctx while dc_dmub_srv is NULL.
5. Induce a kernel crash, display subsystem failure, or system denial of service.

How to detect it

Look for evidence of kernel crashes or oops events involving the AMD display driver and the vulnerable functions. Useful log sources include the kernel ring buffer, systemd journal, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump directories, kdump/vmcore storage, and endpoint telemetry that records kernel panic or unexpected reboot events. Search for NULL pointer dereference messages, call traces referencing dc_dmub_srv_log_diagnostic_data(), dc_dmub_srv_enable_dpia_trace(), dc_dmub_srv.c, amdgpu, drm/amd/display, DC_LOG_ERROR, DMUB, or DPIA trace. Because this issue causes denial of service rather than a reliable persistence or code-execution artifact, detection is primarily crash-forensics based; absence of these logs does not prove the vulnerable code path was never reached, especially if crash dumps are disabled or logs were lost during reboot. No specific public exploit indicators, threat actor tooling, network signatures, or ransomware indicators were provided.

• NULL pointer dereference
• kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic
• Call Trace:
• dc_dmub_srv_log_diagnostic_data
• dc_dmub_srv_enable_dpia_trace
• dc_dmub_srv.c
• drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
• DC_LOG_ERROR
• amdgpu
• drm/amd/display
• DMUB
• DPIA trace
• dc_dmub_srv->ctx
• dc_dmub_srv->dmub
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /var/crash/
• vmcore

What your security team should do

• Inventory Linux systems with AMD GPUs or AMD display driver modules enabled, especially desktops, GPU workstations, kiosks, and systems where graphical availability matters.
• Patch affected systems through the appropriate Linux distribution or vendor kernel update channel and reboot to ensure the fixed kernel is running.
• Prioritize remediation based on operational impact: critical graphical workstations and high-availability systems first; lower-risk non-AMD or headless systems can be deprioritized.
• Restrict local shell, desktop, and device access to trusted users on systems that cannot be patched promptly.
• Add monitoring for kernel NULL pointer dereference, amdgpu, drm/amd/display, dc_dmub_srv, and DMUB-related crash messages in system logs.
• Review crash dumps, kdump artifacts, and system reboot events for evidence of prior kernel oops or panic conditions matching the vulnerable functions.
• Track vendor advisories for exact fixed package versions because no per-package fixed versions were supplied in the input.