CVE-2026-52965

What it actually does

This flaw is a Linux kernel DRM/TTM memory-management bug that can cause an infinite LRU-list walk when TTM buffer-object swapout fails. Instead of continuing past the failed resource, the resource can be moved back in front of the iterator cursor and selected repeatedly, causing kernel CPU consumption and potential soft lockup or system hang. The practical impact is denial of service rather than code execution or data disclosure.

Why it matters to the business

Systems that expose GPU/DRM functionality to users, containers, desktops, VDI sessions, rendering workloads, or compute jobs may be vulnerable to local denial of service. A successful trigger can hang or severely degrade the host, interrupting graphics, compute, desktop, or service workloads until the system recovers or is rebooted. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so urgency is highest for multi-user Linux systems and hosts where untrusted users or workloads can access DRM devices.

How an attack unfolds

An attacker first needs a way to run code on an affected Linux system with access to DRM/TTM-backed GPU resources, commonly through a local account, desktop session, container with GPU device access, or workload using /dev/dri devices. The attacker then creates or manipulates graphics buffer objects and induces memory pressure or swapout activity so that ttm_tt_swapout() fails. When the vulnerable kernel attempts to restore the resource to the LRU handling path, the same resource can be encountered repeatedly by the iterator, causing an infinite loop. The result is a kernel-level denial of service, typically seen as high CPU usage, soft lockup messages, stalled graphics/GPU workloads, or a host hang requiring administrative intervention.

How to fix it

Apply the vendor-provided Linux kernel update that includes the DRM/TTM fix for the ttm_bo_swapout() infinite LRU walk. Because fixed package versions were not provided in the input, use the relevant distribution or kernel vendor advisory to identify the corrected kernel build for each platform. After installing the updated kernel, reboot into the fixed kernel and remove or de-prioritize vulnerable kernels where operationally possible. If immediate patching is not possible, reduce exposure by restricting access to /dev/dri devices, avoiding GPU passthrough to untrusted containers or VMs, limiting local shell access on shared systems, applying cgroup/resource controls to untrusted workloads, and monitoring for memory-pressure-induced GPU/DRM instability. Reboots are only temporary recovery and do not remediate the underlying flaw.

How to confirm the fix worked

Confirm that each system is running a kernel build containing the DRM/TTM patch that defers bulk-move removal to the success path and introduces the corrected unevictable bulk-move handling. Validate with distribution package metadata, kernel changelogs, vendor advisories, or source inspection for changes around ttm_bo_swapout(), ttm_tt_swapout(), ttm_resource_del_bulk_move(), and ttm_resource_del_bulk_move_unevictable(). Confirm the active booted kernel, not just the installed package, using standard OS inventory tooling. Where feasible, verify that untrusted users and workloads no longer have unnecessary access to /dev/dri devices. Avoid destructive proof-of-concept testing on production systems because validation attempts may intentionally hang the host.

Typical attack path

1. Obtain local code execution on an affected Linux host or workload environment.
2. Gain access to DRM/GPU device nodes such as /dev/dri/card* or /dev/dri/renderD*.
3. Allocate and churn DRM/TTM buffer objects while creating memory pressure or conditions that make TTM swapout fail.
4. Trigger the vulnerable ttm_bo_swapout() path so the same resource is repeatedly reprocessed during the LRU walk.
5. Cause kernel CPU exhaustion, soft lockup, graphics subsystem stall, or full host denial of service.

How to detect it

Look for evidence of local denial-of-service activity rather than network exploitation. Primary sources are kernel logs, system journal, crash dumps, watchdog/soft-lockup alerts, GPU/DRM driver logs, EDR telemetry for local processes using DRM devices, and container/runtime logs showing GPU device passthrough. Investigate systems with repeated or unexplained hangs, high kernel CPU usage, watchdog soft lockups, stalled GPU jobs, or kernel traces involving ttm_bo_swapout(), ttm_tt_swapout(), TTM, DRM, or LRU handling. Correlate the timing of kernel lockup messages with local user sessions, batch jobs, containers, or processes opening /dev/dri/card* or /dev/dri/renderD*. Absence of explicit TTM stack traces does not rule out exploitation, because a hard hang may prevent complete logging. Since no public exploit maturity or named threat actors are reported for this input, focus on anomalous local activity and repeated triggering patterns rather than known campaign indicators.

• watchdog: BUG: soft lockup
• BUG: soft lockup
• kernel: BUG: soft lockup
• INFO: rcu_sched detected stalls
• INFO: rcu_preempt detected stalls
• rcu: INFO: rcu_preempt detected stalls
• NMI watchdog: Watchdog detected hard LOCKUP
• ttm_bo_swapout
• ttm_tt_swapout
• ttm_resource_move_to_lru_tail
• ttm_resource_add_bulk_move
• ttm_resource_del_bulk_move
• ttm_resource_del_bulk_move_unevictable
• drm/ttm
• /dev/dri/card
• /dev/dri/renderD

What your security team should do

• Prioritize patching shared Linux workstations, VDI hosts, GPU compute nodes, container platforms with GPU passthrough, and multi-user systems where untrusted workloads can access DRM devices.
• Inventory systems exposing /dev/dri/card* or /dev/dri/renderD* to users, containers, or virtual machines and map them to kernel versions.
• Apply the corrected kernel from the appropriate Linux distribution or vendor and reboot to ensure the fixed kernel is active.
• Temporarily restrict GPU/DRM device access for untrusted users or workloads until patching is complete.
• Add monitoring for kernel soft lockups, GPU/DRM hangs, unexplained high kernel CPU consumption, and repeated TTM-related kernel messages.
• Review recent incidents involving unexplained Linux host hangs or graphics/GPU stalls for possible exploitation or accidental triggering.
• Because this is not currently KEV-listed and has low EPSS, treat it as defense-in-depth for most servers but higher priority for exposed multi-tenant GPU environments.