CVE-2026-43169

What it actually does

This is a local denial-of-service flaw in the Linux kernel Direct Rendering Manager (DRM) buddy memory allocator. When a caller requests a GPU/VRAM allocation with DRM_BUDDY_CONTIGUOUS_ALLOCATION, the allocator rounds the requested size up to the next power of two; for some non-contiguous allocations it rounds the size up to the configured minimum block size. If the rounded value becomes larger than the managed memory region, the allocator can later hit a BUG_ON(order > mm->max_order) condition instead of cleanly rejecting the request. Reaching that BUG_ON can trigger a kernel oops or panic, causing system instability or a crash. The flaw requires local access and low privileges, and impacts availability rather than confidentiality or integrity.

Why it matters to the business

An authenticated local user, compromised workload, or untrusted process with access to DRM/GPU device interfaces may be able to crash the host or make graphics/GPU services unavailable. On desktops and workstations this can cause user disruption, forced reboots, and lost work; on GPU-backed compute, VDI, rendering, or AI/ML systems it can interrupt jobs and reduce platform availability. The vulnerability is not listed in CISA KEV, has no known exploit maturity in the provided data, and has a very low, flat EPSS score, so broad internet-scale exploitation is unlikely; however, systems that expose /dev/dri devices to untrusted users, containers, or shared compute tenants should treat it as a meaningful local availability risk.

How an attack unfolds

An attacker first obtains local code execution on a Linux system where DRM/GPU device nodes are accessible. The attacker then interacts with a DRM driver path that uses the kernel drm_buddy allocator for VRAM or graphics memory management. By submitting an allocation request whose original size is within a plausible range but whose rounded allocation size exceeds the allocator's managed memory size, the attacker can drive the allocator into an invalid order calculation. For example, a request near the VRAM size may be rounded up to a larger power-of-two value for a contiguous allocation, or rounded up to a large minimum block size for a non-contiguous allocation. Vulnerable kernels may then reach the BUG_ON(order > mm->max_order) assertion rather than returning an error. Depending on kernel configuration and runtime behavior, this can produce an oops, panic, GPU driver failure, or full host reboot. There is no indication from the provided data that this is being exploited by named threat actors or ransomware campaigns.

How to fix it

Upgrade to a Linux kernel build that includes the drm/buddy fix validating rounded allocation sizes against mm->size before continuing allocation processing. No exact fixed package versions were provided, so use the fixed kernel versions supplied by the relevant Linux distribution, hardware vendor, cloud image provider, or kernel stable branch once available. Where immediate patching is not possible, reduce exposure by limiting access to DRM/GPU device nodes to trusted users and workloads only, removing unnecessary users from video/render groups, applying device cgroup restrictions for containers, avoiding passthrough of /dev/dri into untrusted containers, and disabling or isolating GPU access on multi-user systems where practical. Because this is a kernel issue, a reboot into the patched kernel is required after installation; merely installing packages without booting the fixed kernel is insufficient.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, is a vendor build that contains the drm/buddy rounded-allocation validation fix. Check distribution security advisories or kernel changelogs for references to the drm/buddy fix, validation of rounded allocation against mm->size, or prevention of BUG_ON(order > mm->max_order). Verify that the host has rebooted into the fixed kernel using standard OS commands such as uname -r and package-manager queries. For exposure validation, inventory systems with GPU/DRM support and check permissions on /dev/dri/card* and /dev/dri/renderD* to identify whether untrusted users or containers can access DRM devices. In controlled non-production testing only, confirm that malformed or oversized allocation requests return an error or take the safe fallback path rather than producing a kernel BUG, oops, or panic.

Typical attack path

1. Gain local execution on a Linux host, workstation, container host, or GPU-enabled compute node.
2. Confirm that the process can access DRM/GPU device nodes such as /dev/dri/card* or /dev/dri/renderD*.
3. Invoke a DRM/GPU allocation path that uses the kernel drm_buddy allocator.
4. Request a large allocation that is rounded above the allocator's managed memory size, such as a near-VRAM-size contiguous allocation or a request aligned to a very large minimum block size.
5. Trigger the vulnerable BUG_ON condition in the kernel allocator.
6. Cause a kernel oops, panic, GPU subsystem failure, service disruption, or host reboot.

How to detect it

Look for evidence of prior kernel crashes or GPU subsystem failures rather than remote network indicators. Relevant sources include kernel ring buffer logs, system journal, syslog/kern.log/messages, pstore/ramoops, kdump/vmcore artifacts, crash reports, hypervisor reset events, endpoint telemetry, and audit logs showing access to DRM device nodes before a crash. Search for kernel BUG, oops, panic, or assertion messages involving drm_buddy allocation routines, order calculations, max_order, or DRM/GPU memory allocation failures. Correlate these events with local process execution and device access to /dev/dri/card* or /dev/dri/renderD*, especially by unusual users, newly deployed workloads, containers, CI jobs, or untrusted interactive sessions. Because the vulnerability causes availability impact and may reboot the system quickly, persistent logs such as journald with persistent storage, pstore, kdump, and centralized log forwarding are important for after-the-fact detection. There are no known network IOCs or named actor tradecraft in the provided data.

• BUG_ON(order > mm->max_order)
• order > mm->max_order
• drm_buddy
• drm_buddy_alloc
• DRM_BUDDY_CONTIGUOUS_ALLOCATION
• kernel BUG
• kernel panic
• Oops:
• /dev/dri/card
• /dev/dri/renderD
• pstore
• ramoops
• vmcore
• roundup_pow_of_two
• round_up

What your security team should do

• Prioritize patching shared GPU, VDI, rendering, desktop fleet, AI/ML, and multi-user Linux systems where untrusted or semi-trusted users can access DRM/GPU devices.
• Inventory Linux systems exposing /dev/dri/card* or /dev/dri/renderD* to users, containers, CI jobs, notebooks, or hosted workloads.
• Apply vendor kernel updates that include the drm/buddy allocation-size validation fix, then reboot into the fixed kernel.
• Restrict DRM/GPU device access to trusted principals only by reviewing video/render group membership, udev rules, container runtime device mappings, and device cgroup policies.
• For containerized environments, avoid passing /dev/dri devices into untrusted containers unless required and protected by isolation controls.
• Monitor kernel, journald, pstore, and crash-dump sources for BUG, oops, panic, or drm_buddy-related failures, especially on GPU-enabled hosts.
• Treat repeated local crashes associated with DRM allocation paths as potential abuse, even though current public exploitation likelihood is low.