CVE-2026-53285
NoneCVSS
—
EPSS
0.1%
Published
Jun 26, 2026
CISA due date
—
Cloudanix analysis
Certain Linux systems with AMD graphics can crash during display changes unless the operating system is updated.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Denial of service
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
This flaw is a Linux kernel denial-of-service condition in the AMD display driver. A display bandwidth validation path can allocate a large dc_plane_state object through kvzalloc()/vmalloc() while execution is inside an FPU-protected region where local softirqs are disabled. That invalid context can hit the kernel BUG_ON(in_interrupt()) check in the vmalloc path, causing a kernel BUG/panic and crashing the system. The issue is reliability-impacting rather than a confidentiality or privilege-escalation flaw based on the available description.
Why it matters to the business
Systems using affected Linux kernels with AMD display hardware may crash when display configuration paths trigger the vulnerable code, causing workstation, kiosk, appliance, or graphics-enabled server downtime. The public exploit maturity is currently listed as none, EPSS is very low, and it is not in CISA KEV, so broad internet-scale exploitation is unlikely; however, crashes can still disrupt operations where graphical availability or local user sessions matter.
How an attack unfolds
An attacker needs a way to exercise the AMD display driver path that validates display bandwidth and enables a DCN32 phantom plane. In a plausible local scenario, the attacker changes display modes, connects or emulates display outputs, or otherwise causes display reconfiguration that reaches dcn32_validate_bandwidth(), which enters an FPU-protected section. The vulnerable path then calls dcn32_enable_phantom_plane(), which attempts to allocate roughly 335 KiB for dc_plane_state using kvzalloc(). Because that allocation can take the vmalloc path while softirqs are disabled, the kernel detects allocation from an invalid interrupt-like context and triggers a BUG, resulting in a kernel panic or display subsystem crash. There is no indication from the provided data that the flaw enables code execution, data theft, or remote exploitation by itself.
How to fix it
Upgrade to a Linux kernel version that includes the upstream fix for the AMD display driver change wrapping dc_state_create_phantom_plane() with DC_RUN_WITH_PREEMPTION_ENABLED(). If using a distribution kernel, apply the vendor security or stable kernel update that backports the fix. If immediate patching is not possible, reduce exposure by limiting untrusted local access to graphical sessions, avoiding unnecessary display hotplug or mode-switch automation on affected AMD GPU systems, and considering temporary use of a non-vulnerable kernel branch or a configuration that does not load the affected amdgpu display path where operationally feasible. No exact affected package list or fixed version set was provided, so rely on Linux distribution advisories and kernel changelogs referencing the AMD display phantom-plane allocation fix or upstream commit 885ccbef7b94a8b38f69c4211c679021aa27ad11.
How to confirm the fix worked
Confirm the running kernel includes the fix by checking the distribution changelog, kernel source, or backport notes for the AMD display patch that wraps dc_state_create_phantom_plane() in DC_RUN_WITH_PREEMPTION_ENABLED(). On source-based or internally built kernels, verify the amdgpu display code no longer performs the phantom-plane allocation inside the DC_FP_START()/DC_FP_END() protected section without temporarily enabling preemption. Operationally, validate by exercising normal display mode changes and multi-display workflows on a patched test system while monitoring dmesg/journalctl for kernel BUG, vmalloc, in_interrupt, or amdgpu display errors. Also confirm the installed and running kernel versions match the remediated package, since rebooting is required after most kernel updates.
Typical attack path
- Obtain local or otherwise authorized ability to trigger display configuration changes on a system using the affected AMD display driver path.
- Cause display bandwidth validation to run, such as through mode setting, display hotplug, multi-monitor configuration changes, or graphics stack operations.
- Reach the DCN32 DML1 phantom-plane creation path while the driver is inside the FPU-enabled region with softirqs disabled.
- Trigger the large dc_plane_state allocation through kvzalloc()/vmalloc() in the invalid execution context.
- Cause the kernel BUG/panic condition, resulting in system crash or service interruption.
How to detect it
Look for evidence of prior kernel crashes or panics around display reconfiguration on AMD GPU systems. Primary log sources are kernel ring buffer logs, persistent system journal entries, /var/log/kern.log, /var/log/messages, crash dump metadata, pstore/ramoops records, and kdump/vmcore analysis. Search for kernel BUG or panic messages that mention vmalloc allocation from an invalid context, in_interrupt checks, amdgpu, drm/amd/display, DCN32, phantom plane, or dcn32_validate_bandwidth. Correlate timestamps with display hotplug events, monitor mode changes, graphical session starts, compositor restarts, Xorg/Wayland logs, or user reports of sudden reboot/freeze. Because this issue is a crash condition rather than a known malware technique, absence of a distinctive payload IOC does not rule out triggering; focus on crash signatures and call traces involving the affected AMD display functions.
- BUG_ON(in_interrupt())
- kernel BUG at mm/vmalloc
- kernel BUG at mm/vmalloc.c
- BUG: kernel NULL pointer dereference
- Kernel panic - not syncing
- Oops: 0000
- amdgpu
- drm/amd/display
- dcn32_validate_bandwidth
- dcn32_internal_validate_bw
- dcn32_enable_phantom_plane
- dc_state_create_phantom_plane
- dc_plane_state
- kvzalloc
- vmalloc
- DC_FP_START
- DC_FP_END
- DC_RUN_WITH_PREEMPTION_ENABLED
- in_interrupt()
What your security team should do
- Inventory Linux systems with AMD GPUs or AMD display driver support enabled, prioritizing workstations, kiosks, VDI endpoints, and graphics-enabled appliances where a crash has operational impact.
- Patch affected systems to a vendor kernel containing the AMD display phantom-plane allocation fix, then reboot into the updated kernel.
- Because EPSS is very low, exploit maturity is none, and the issue is not in KEV, prioritize according to operational exposure rather than emergency internet-facing risk; still treat shared workstations and untrusted local-user systems as higher priority.
- Monitor kernel logs for BUG/panic events involving amdgpu, drm/amd/display, vmalloc, or in_interrupt to identify systems that may have already encountered the crash condition.
- Restrict untrusted local interactive access on high-availability graphical systems until patched.
- For custom kernels, backport the upstream fix associated with commit 885ccbef7b94a8b38f69c4211c679021aa27ad11 and regression-test display hotplug and mode-setting scenarios.
The record
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Wrap DCN32 phantom-plane allocation in DC_RUN_WITH_PREEMPTION_ENABLED [Why] dcn32_validate_bandwidth() wraps dcn32_internal_validate_bw() with DC_FP_START()/DC_FP_END(). In x86 non-RT, DC_FP_START takes fpregs_lock(), which disables local softirqs. The DML1 path through dcn32_enable_phantom_plane() calls kvzalloc() to allocate ~335 KiB for dc_plane_state. This triggers the vmalloc path, which calls BUG_ON(in_interrupt()) because it's invoked within the FPU-enabled (softirq disabled) region, leading to a kernel crash. [How] Wrap the dc_state_create_phantom_plane() call with the DC_RUN_WITH_PREEMPTION_ENABLED() macro to allow preemption during this memory allocation. (cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11)
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|