CVE-2026-53316

What it actually does

This is a Linux kernel denial-of-service flaw in the AMD DRM/RAS error-handling path. When the AMD GPU RAS core pointer is NULL, the function ras_core_ras_interrupt_detected() can still attempt to access ras_core->dev, causing a NULL pointer dereference. Depending on kernel configuration and runtime settings, this may result in a kernel oops, GPU driver failure, system instability, or a full kernel panic and reboot. The vulnerability is not described as enabling privilege escalation, information disclosure, or remote code execution.

Why it matters to the business

Systems using affected Linux kernels with AMD GPU/RAS functionality may be exposed to unexpected crashes or service interruptions if the vulnerable code path is triggered. The operational risk is highest for GPU-dependent workloads such as compute nodes, graphics workstations, virtual desktop infrastructure, rendering farms, or AI/ML systems where a kernel crash or GPU driver failure can interrupt jobs and require manual recovery. This issue is not currently listed in CISA KEV, has very low EPSS, and has no known public exploit maturity in the provided data, so it should generally be prioritized as a stability and availability fix rather than an active widespread exploitation emergency.

How an attack unfolds

An attacker would need to reach a condition that causes the AMD DRM/RAS interrupt detection error path to execute while the RAS core object is NULL. In a realistic scenario, this would most likely require local access to a system with an affected kernel and AMD GPU driver stack, or the ability to influence GPU/RAS-related operations through exposed local GPU interfaces. Once the vulnerable path is triggered, the kernel attempts to dereference a NULL pointer, producing an oops or panic. If the system is configured to panic on oops, this can force a reboot; otherwise, the affected driver or kernel subsystem may become unstable. There is no indication from the provided data that the flaw is remotely exploitable or currently used by named threat actors.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the AMD DRM/RAS NULL pointer dereference in ras_core_ras_interrupt_detected(). Because no product-specific package list or fixed version was provided, use the fixed kernel version supplied by the relevant Linux distribution or vendor advisory once available. For systems that compile custom kernels, incorporate the upstream drm/amd/ras patch that prevents dereferencing ras_core when it is NULL. Where immediate patching is not possible, reduce exposure by limiting untrusted local access to GPU devices, restricting membership in groups that can access /dev/dri/*, disabling unnecessary GPU/RAS functionality where operationally acceptable, and avoiding kernel configurations that turn recoverable oops conditions into full system panics unless required by policy.

How to confirm the fix worked

Confirm the running kernel includes the fix by checking the distribution/vendor security advisory or kernel changelog for the AMD DRM/RAS NULL dereference fix in ras_core_ras_interrupt_detected(). On source-based or custom kernels, verify the patched code checks ras_core before accessing ras_core->dev in the error path. Confirm the active runtime kernel is the updated one after reboot using standard kernel version checks such as uname -r and package manager queries. Review whether AMD GPU DRM/RAS support is present by checking loaded modules such as amdgpu and the existence of GPU device nodes under /dev/dri/. For exposure validation, prioritize systems with AMD GPUs, amdgpu loaded, and workloads that allow local users or containers to interact with GPU devices.

Typical attack path

1. Identify a Linux system running an affected kernel with AMD DRM/amdgpu RAS support enabled or present.
2. Obtain local ability to interact with GPU-related functionality or otherwise influence AMD GPU error/RAS handling paths.
3. Trigger an AMD GPU RAS interrupt detection or related error-handling condition where the RAS core pointer is NULL.
4. Cause ras_core_ras_interrupt_detected() to access ras_core->dev despite ras_core being NULL.
5. Induce a kernel NULL pointer dereference, resulting in a kernel oops, driver instability, system hang, panic, or reboot.

How to detect it

Look for evidence of prior kernel crashes or oops events involving the AMD GPU RAS path. Useful sources include systemd journal logs, kernel ring buffer output, /var/log/kern.log, /var/log/messages, /var/log/syslog, persistent crash dump systems such as kdump, and monitoring records showing unexpected reboots or node failures. Search for NULL pointer dereference messages near references to amdgpu, DRM, RAS, or ras_core_ras_interrupt_detected(). Correlate these events with GPU workload activity, local user sessions, container jobs with GPU access, or repeated crashes on the same AMD GPU-equipped systems. Because the provided intelligence does not identify a public exploit, named threat actor, or remote attack vector, detection should focus on crash forensics and repeated local-trigger patterns rather than network indicators.

• ras_core_ras_interrupt_detected
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• amdgpu
• drm/amd/ras
• ras_core->dev
• /dev/dri/card
• /dev/dri/renderD
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• kdump
• vmcore

What your security team should do

• Inventory Linux systems with AMD GPUs or the amdgpu kernel driver loaded, especially GPU compute, rendering, workstation, and VDI systems.
• Track the relevant Linux distribution or kernel vendor advisory and patch affected kernels when fixed packages are available.
• Prioritize patching shared multi-user GPU systems and production GPU workloads where a crash would cause material downtime or job loss.
• Restrict access to GPU device files such as /dev/dri/* to trusted users and workloads until patched.
• Review kernel crash, oops, and reboot telemetry for signs of AMD DRM/RAS-related NULL pointer dereferences.
• For custom kernel builds, incorporate the upstream drm/amd/ras fix and validate the corrected NULL check before deployment.
• Because the issue is not KEV-listed and has low EPSS in the provided data, handle it through normal kernel maintenance unless local abuse indicators or unexplained GPU-node crashes are observed.