CVE-2026-53315

What it actually does

This is a Linux kernel NULL pointer dereference in the AMD GPU Reliability, Availability, and Serviceability (RAS) code path. The vulnerable function, ras_core_get_utc_second_timestamp(), attempts to log an error by accessing ras_core->dev after a conditional path where ras_core may be NULL. If that code path is reached, the kernel can dereference a NULL pointer, typically causing an oops or panic depending on kernel configuration and runtime handling. The practical impact is denial of service rather than code execution: a local or otherwise privileged path that can trigger the affected AMD RAS timestamping logic may crash the system or destabilize GPU/RAS error handling.

Why it matters to the business

Successful exploitation can interrupt workloads running on affected Linux systems, especially systems using AMD GPU hardware and kernel RAS functionality. The likely consequence is unplanned reboot, service interruption, failed compute jobs, or degraded availability of GPU-backed infrastructure. The risk is currently lower than broadly exploitable remote vulnerabilities because there is no known public exploit, EPSS is very low, it is not listed in CISA KEV, and it is not known to be used in ransomware campaigns; however, kernel crashes can still create meaningful operational disruption in high-availability, HPC, AI/ML, VDI, or graphics-intensive environments.

How an attack unfolds

An attacker would need a way to reach the vulnerable AMD DRM/RAS kernel code path where ras_core_get_utc_second_timestamp() is invoked while the ras_core pointer is NULL. In a typical scenario, this would require local access, access to GPU-related interfaces, or the ability to influence RAS/error-reporting behavior on a system using affected AMD GPU kernel drivers. The attacker then triggers an AMD RAS event or error-reporting path that calls the vulnerable function. When the function attempts to print the error using ras_core->dev despite ras_core being NULL, the kernel dereferences address zero. Depending on kernel settings, this results in a kernel oops, GPU driver failure, or full system panic/reboot. There is no indication from the provided data of active exploitation, weaponized exploit code, or remote unauthenticated exploitation.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the AMD DRM/RAS NULL dereference in ras_core_get_utc_second_timestamp(). Where vendor kernels are used, upgrade to the relevant distribution, appliance, cloud image, or hardware-vendor kernel package that backports this fix. If immediate patching is not possible, reduce exposure by limiting untrusted local access, restricting access to GPU device nodes where operationally feasible, disabling or avoiding AMD GPU/RAS functionality only if supported and acceptable, and ensuring systems are configured for safe recovery from kernel panics. Because no exact affected products or fixed package versions were provided, use the operating system or kernel vendor advisory to identify the corrected kernel build for each deployed platform.

How to confirm the fix worked

Confirm that systems are running a kernel build containing the AMD DRM/RAS fix. Validate through vendor package changelogs, kernel git commit history, or distribution security advisories referencing the ras_core_get_utc_second_timestamp() NULL dereference fix. On representative systems, verify the running kernel version with uname -r and compare it to the vendor-fixed build after rebooting into the updated kernel. Review dmesg and journal logs after patching to ensure there are no recurring AMDGPU RAS errors, kernel oopses, or panics related to ras_core_get_utc_second_timestamp(). If GPU workloads are important, perform controlled regression testing of AMD GPU workloads and RAS/error-monitoring functions after the update.

Typical attack path

1. Identify a Linux system running an affected kernel with AMD DRM/RAS functionality present.
2. Obtain local execution capability or another path that can interact with GPU/RAS-related kernel interfaces.
3. Trigger an AMD RAS timestamping/error-reporting path where ras_core_get_utc_second_timestamp() is called while ras_core is NULL.
4. Cause the kernel to dereference ras_core->dev when ras_core is invalid.
5. Induce a kernel oops, panic, reboot, or GPU subsystem instability, resulting in denial of service.

How to detect it

Look for evidence of kernel crashes or GPU driver instability rather than traditional intrusion artifacts. Useful sources include kernel ring buffer logs, system journal, /var/log/kern.log, /var/log/messages, crash dump infrastructure such as kdump/vmcore, hypervisor reset telemetry, workload scheduler failure logs, and GPU monitoring logs. Search for NULL pointer dereference, kernel oops, panic, or call traces involving AMDGPU RAS functions, especially ras_core_get_utc_second_timestamp(), drm/amd/ras, amdgpu, or RAS timestamping immediately before an unexpected reboot or node disappearance. Because this flaw is a denial-of-service bug and no public exploit or threat actor activity is indicated, detection should focus on repeated, unexplained crashes correlated with AMDGPU RAS errors and local user activity rather than network indicators. If crash dumps are available, inspect stack traces for the vulnerable function and confirm whether ras_core was NULL at the time of the fault.

• ras_core_get_utc_second_timestamp
• drm/amd/ras
• amdgpu ras
• AMDGPU RAS
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• Call Trace:
• ras_core->dev

What your security team should do

• Prioritize patching affected Linux systems with AMD GPUs or AMDGPU RAS functionality, especially production GPU compute, AI/ML, HPC, VDI, and high-availability systems.
• Track the relevant Linux distribution or hardware-vendor advisory because fixed versions are kernel/package specific and were not provided in the input.
• Restrict untrusted local shell access and unnecessary access to GPU device files on shared systems until patched.
• Review crash, reboot, and kernel panic telemetry for signs of recurring AMDGPU/RAS-related instability since publication.
• Ensure kernel panic/reboot handling, workload checkpointing, and monitoring are configured to reduce operational impact from denial-of-service conditions.
• Do not treat this as a likely ransomware or internet-scale exploitation issue based on current metadata: EPSS is very low, exploit maturity is none, and it is not in CISA KEV.