CVE-2026-52949

What it actually does

This flaw is a Linux kernel denial-of-service issue in the DRM TTM memory-management subsystem used by graphics drivers. Under a backup failure in the ttm_bo_shrink() path, a buffer object can be removed from bulk-move tracking before the operation has actually succeeded, which can leave the shrinker repeatedly walking the same LRU state instead of making forward progress. The practical result is a potential infinite LRU walk, high CPU consumption, kernel soft lockup, hung task, graphics subsystem stall, or broader system unresponsiveness when GPU/TTM memory pressure and backup-failure conditions are triggered.

Why it matters to the business

Successful exploitation can degrade or interrupt systems that rely on affected Linux kernels and DRM/TTM-backed graphics or GPU memory management. Workstations, virtual desktop hosts, GPU-enabled servers, CI/build systems, rendering nodes, and container platforms that expose /dev/dri devices could experience hangs, service interruption, or require rebooting. Current public exploitation signals are low: EPSS is very low, no known CISA KEV listing is present, and no mature public exploit is indicated; however, kernel denial-of-service bugs can still be operationally important where local users, tenants, containers, or untrusted workloads can access GPU devices.

How an attack unfolds

An attacker generally needs local code execution or access to an interface that can exercise DRM/TTM GPU buffer-object allocation and memory-pressure behavior, such as a render node exposed through /dev/dri. The attacker causes repeated graphics memory activity and conditions that make backup or swap-like handling fail. When the vulnerable shrink path is reached, the kernel may repeatedly traverse the same LRU entries without forward progress. This can pin CPU time in kernel context, trigger watchdog soft-lockup or hung-task conditions, stall graphics-related workloads, and potentially make the host or affected service unavailable until pressure subsides or the system is rebooted.

How to fix it

Apply a Linux kernel update that includes the upstream DRM/TTM fix for the ttm_bo_shrink() infinite LRU walk on backup failure. Because no product-specific fixed versions were provided, use the latest security-supported kernel from the operating-system or appliance vendor and verify that the vendor advisory includes the corresponding DRM/TTM patch. Where immediate patching is not possible, reduce exposure by limiting access to /dev/dri devices, avoiding GPU device passthrough to untrusted containers or virtual machines, disabling unnecessary graphics/GPU acceleration on servers, enforcing least-privilege device cgroup policies, and monitoring for kernel lockup symptoms. Reboots are typically required after kernel updates to activate the fixed kernel.

How to confirm the fix worked

Confirm the running kernel is the remediated version, not merely that an updated package is installed. On Linux systems, compare `uname -r` with the vendor-fixed kernel version and verify package-manager output such as `rpm -q kernel`, `dpkg -l 'linux-image*'`, or the distribution's security advisory metadata. Validate that systems with GPUs or exposed /dev/dri devices have been rebooted into the patched kernel. For source-built kernels, confirm the DRM/TTM change is present in the kernel tree and that the active kernel image was rebuilt and deployed. Exposure can be checked by identifying systems with DRM devices present under /dev/dri and workloads or containers granted access to those devices.

Typical attack path

1. Obtain local execution on a Linux system running an affected kernel with a DRM/TTM-backed graphics driver available.
2. Gain access to GPU/render interfaces, commonly through /dev/dri/card* or /dev/dri/renderD* device nodes, either directly or from a container/VM/workload where those devices are passed through.
3. Create sustained GPU buffer-object allocation, eviction, shrink, or memory-pressure activity to exercise the TTM shrinker path.
4. Induce or wait for backup-failure conditions during ttm_bo_shrink() processing.
5. Trigger the infinite LRU-walk behavior, causing high kernel CPU usage, soft lockups, hung tasks, graphics stalls, or system unresponsiveness.
6. Maintain pressure or repeat the trigger to prolong denial of service until the system is patched, the device access is removed, or the host is rebooted.

How to detect it

To determine whether this was already triggered, review kernel and system logs for denial-of-service symptoms around graphics memory pressure: soft lockups, hung tasks, watchdog reports, repeated DRM/TTM stack traces, GPU reset messages, unexplained load spikes, and abrupt reboots. Useful log sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dumps, kdump/vmcore data, hypervisor reset logs, container runtime audit logs showing device passthrough, and EDR telemetry for processes using /dev/dri devices shortly before lockups. Correlate events with local users, containers, batch jobs, browser/GPU-accelerated workloads, rendering jobs, or test harnesses that performed heavy GPU buffer allocation. There are no known public attacker-specific IOCs for this issue; detection should focus on kernel-behavior artifacts and suspicious access to DRM render devices before availability failures.

• ttm_bo_shrink
• drm/ttm
• ttm_bo_swapout
• ttm_resource_del_bulk_move
• watchdog: BUG: soft lockup
• BUG: soft lockup
• INFO: task
• blocked for more than
• hung_task_timeout_secs
• NMI watchdog: Watchdog detected hard LOCKUP
• kernel: drm
• /dev/dri/card
• /dev/dri/renderD
• GPU HANG
• Resetting chip for hang
• drm_sched_job_timedout

What your security team should do

• Prioritize patching Linux systems that expose GPU/render devices to untrusted users, multi-tenant workloads, containers, CI jobs, VDI sessions, or virtual machines.
• Inventory Linux hosts with /dev/dri/card* or /dev/dri/renderD* devices and map which workloads can access them.
• Deploy the latest vendor-supported kernel containing the DRM/TTM fix and reboot systems to ensure the fixed kernel is active.
• Temporarily remove GPU device passthrough from untrusted containers or VMs where patching is delayed.
• Restrict device access using Unix permissions, groups, udev rules, container device policies, and cgroup device controls.
• Monitor kernel logs for soft lockups, hung tasks, DRM/TTM stack traces, unexplained GPU stalls, and forced reboots.
• Treat repeated kernel lockups on GPU-enabled systems as potential abuse until ruled out, even though known exploitation maturity is currently low.