EUVD-2026-93094
GHSA-62xr-3qf5-9qpj
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessLocal user triggers hibernation/swapout cycle
-
DeliveryTTM leaves swapped resource in bulk_move
-
ExploitFreed range endpoint dangles on manager LRU
-
ExecutionLater LRU walk dereferences stale cursor
-
ImpactUse-after-free crashes kernel
Vulnerability Assessment
| Exploitation Conditions | Requires an affected Linux kernel (regression present from commit b2ed01e7ad3d, i.e. roughly 7.0.10 up to before 7.1 and related stable backports such as Ubuntu 7.0.0-31) running a drm/ttm-backed GPU driver - demonstrated on an AMD Phoenix APU (gfx1103) using amdgpu. The fault is triggered when TTM swaps out populated graphics memory, in practice via suspend-then-hibernate, memory pressure, or BO teardown at process exit/reboot following a hibernation. Limiting factors: local presence and local activity are required (AV:L); the bug is race/timing-dependent (crashed only 5 of 18 hibernation cycles, manifesting minutes to hours later), it depends on an active GPU workload with bulk_move resources, and hibernation/swapout is typically needed - it is not remotely reachable and not attacker-controllable toward a deterministic primitive. |
| Impact | Signals point to a genuine but low-urgency local kernel reliability bug rather than a high-value exploitation target. The provided CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N, C:H/I:H/A:H → 7.8 HIGH) reflects a kernel use-after-free, which in principle can yield memory corruption, but the mechanism described is a dangling bulk_move cursor triggered by TTM swapout during hibernation/suspend - not an attacker-steered primitive. EPSS is very low (0.20%, 9th percentile) and there is no KEV listing and no public exploit, all consistent with a crash/stability defect rather than a weaponized flaw. Note a tension worth flagging: the CVSS assigns C:H/I:H/A:H and AC:L, yet the report characterizes the fault as a timing-dependent crash that manifested in only 5 of 18 hibernation cycles and surfaces as WARNs, list corruption, or NULL dereference - behavior that reads as denial-of-service (matching the 'Denial Of Service' tag) with a race condition (arguably AC:H), not reliable confidentiality/integrity compromise. Treat the high CVSS as an upper-bound theoretical rating; real-world priority is patch-on-schedule, not emergency. |
| Exploit ScenarioDerived | A low-privileged local user (or normal desktop workload) on an affected AMD-GPU Linux system triggers graphics memory swapout via a suspend-then-hibernate cycle; TTM fails to remove the swapped-out resource from its BO's bulk_move range, leaving a cursor pointing at freed memory. Minutes to hours later - during a subsequent LRU walk, at process exit, or on reboot - the dangling cursor is dereferenced, causing a use-after-free that crashes the kernel. No public exploit exists; the defect is timing-dependent and demonstrated as a stability crash rather than a controlled code-execution chain. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Use-after-free in the Linux kernel's drm/ttm graphics memory manager (a regression introduced by commit b2ed01e7ad3d, present in roughly 7.0.10 through 7.1 and in stable backports such as Ubuntu 7.0.0-31) allows a locally authenticated user with an active GPU workload to crash the kernel minutes to hours after a swapout event. Because ttm_bo_swapout_cb() skips the bulk_move bookkeeping on successful swapout, a swapped-out resource stays on its buffer object's bulk_move range and on the manager LRU while being unevictable; when it is later freed or the BO leaves the bulk_move, ttm_resource_del_bulk_move() skips it due to its unevictable guard, leaving a dangling cursor that the next ttm_lru_bulk_move_tail() or ttm_resource_add_bulk_move() dereferences. Exploitation requires local presence, an affected AMD/drm-ttm system, and timing-dependent hibernation or memory-pressure conditions (the reporter observed crashes in only 5 of 18 hibernation cycles), and no public exploit code has been identified at time of analysis; EPSS is 0.20% (9th percentile), signalling low near-term exploitation likelihood.
RemediationAI
Vendor-released patch: update to a kernel containing commit 1169fe8c11ca45e3f91d59a73eb271d0ca8a7fb0 (stable backport) or 3db7d7d583419f7b1f2e141e36418802dbb25cf8 (mainline), i.e. Linux 7.2.8 / 7.3-rc4 or the corresponding 7.0.y/7.1 stable release; the corrected logic restores the ttm_resource_del_bulk_move_unevictable()/ttm_resource_move_to_lru_tail() pair whenever ttm_tt_swapout() returns a positive page count, so the removal happens for every swapped-out resource. Where patching is not immediately possible, the only meaningful compensating controls are to avoid hibernation and suspend-then-hibernate on affected kernels (the demonstrated trigger and the dominant practical failure path; trade-off: loses power-saving and session-persistence functionality), to reduce graphics memory pressure that forces TTM swapout -- for example by limiting GPU workload or lowering the resolution/VRAM footprint of amdgpu applications -- and to reboot or restart the GPU workload after any resume from hibernation rather than continuing to run long sessions, since the dangling bulk_move cursor manifests minutes to hours later at process exit or reboot; there is no configuration switch to disable drm/ttm bulk_move for amdgpu VM BOs, so disabling the GPU driver or avoiding amdgpu in favour of non-TTM drivers is the only complete functional workaround and is generally impractical on affected AMD hardware. Patch availability is confirmed by the vendor (Linux), and reference material is at https://nvd.nist.gov/vuln/detail/CVE-2026-98166 and https://vuldb.com/vuln/414022.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected subsystem is drm/ttm, the Translation Table Manager (TTM) memory manager used by DRM/KMS drivers -- notably amdgpu -- to manage buffer object (BO) placement and eviction across VRAM, GTT and system memory. TTM tracks evictable resources in manager LRUs and, for BOs with bulk_move enabled (used by the amdgpu VM for page-table BOs), in per-BO bulk_move ranges with first/last cursor endpoints. ttm_tt_swapout() returns the number of pages swapped out on success and a negative errno on failure, and never returns zero for a populated ttm. Commit b2ed01e7ad3d ('drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure') guarded the ttm_resource_del_bulk_move_unevictable()/ttm_resource_move_to_lru_tail() pair with 'if (!ret)', which is false on every successful swapout, whereas the analogous shrinker fix 1d59f36e95f7 correctly tested 'lret > 0'. The root-cause class is a use-after-free/dangling-pointer defect (CWE-416 in common taxonomy; the upstream record lists CWE: N/A): the stale endpoint in pos->first/pos->last points at freed memory once ttm_resource_free() or ttm_bo_set_bulk_move() (via amdgpu_vm_bo_del()) runs, and the next bulk-move list operation dereferences it, producing a reservation-object WARN in ttm_lru_bulk_move_add(), 'list_del corruption' in ttm_resource_move_to_lru_tail(), or a NULL dereference in ttm_resource_manager_next(). The reporter reproduced this on an AMD Phoenix APU (ASUS UM3406GA, gfx1103) running suspend-then-hibernate on a 7.0.y stable kernel with the backport (Ubuntu 7.0.0-31), profiling 336 ttm_tt_swapout() calls and zero ttm_resource_del_bulk_move_unevictable() calls in a single failed cycle. CPE data identifies the generic linux:linux product; the practical blast radius is limited to systems using drm/ttm-backed GPU drivers, particularly AMD amdgpu hardware.
Know when Amd gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Local kernel use-after-free reachable only through timing-dependent hibernation/swapout races, so AV:L and AC:H; a low-privileged local user can trigger the path, so PR:L.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: fix swapped-out resources never leaving their bulk_move range
ttm_tt_swapout() returns the number of pages swapped out on success and a negative error code on failure; for a populated ttm it never returns zero. Commit b2ed01e7ad3d ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") moved the bulk_move bookkeeping in ttm_bo_swapout_cb() under "if (!ret)", so the ttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail() pair is now skipped on every successful swapout. The equivalent change for the shrinker in commit 1d59f36e95f7 ("drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure") tests "lret > 0", which is what was intended here as well.
Before b2ed01e7ad3d the resource was taken off the bulk_move before the swapout; since then a swapped-out resource stays inside its BO's bulk_move range (and on the manager LRU) although it is unevictable. When it is later freed or the BO leaves the bulk_move (ttm_resource_free(), ttm_bo_set_bulk_move() via amdgpu_vm_bo_del()), ttm_resource_del_bulk_move() skips it because of its !ttm_resource_unevictable() guard, so a range endpoint in pos->first / pos->last is left pointing at freed memory. The next ttm_lru_bulk_move_tail() or ttm_resource_add_bulk_move() on that cursor is a use-after-free, seen as the resv WARN in ttm_lru_bulk_move_add(), "list_del corruption" in ttm_resource_move_to_lru_tail() or a NULL dereference in ttm_resource_manager_next() -- minutes to hours after a hibernation, or at process exit / reboot following one. Samuel Ainsworth's analysis of drm/amd issue 5387 (see Link) identified the dangling cursor; the missing removal at swapout time is the reason it dangles.
Testing the condition for success restores the removal. On an AMD Phoenix APU (ASUS UM3406GA, gfx1103) running suspend-then-hibernate on a 7.0.y stable kernel carrying the backport (Ubuntu 7.0.0-31) the bug crashed 5 of 18 hibernation cycles; a function profile of one hibernation showed 336 ttm_tt_swapout() calls and zero ttm_resource_del_bulk_move_unevictable() calls. With this change the removal happens for every swapped-out resource and 12 further cycles were clean.
Executive ViewAI
A use-after-free regression in the Linux kernel's DRM/TTM graphics memory manager can crash affected AMD GPU systems, causing unplanned downtime for GPU workstations, virtual desktop infrastructure, and Linux servers running kernels from roughly 7.0.10 through 7.1, including stable backports such as Ubuntu 7.0.0-31. Triggering it requires a local user already present on the machine, an active GPU workload, and memory-pressure or hibernation conditions that only reproduced in a minority of observed cycles, so the exposure is concentrated in shared, GPU-accelerated environments rather than remote or internet-facing attack paths; no public exploit code has been identified at time of analysis. Because patch availability is confirmed, this is best handled as a scheduled kernel remediation and change-management priority rather than an emergency response.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
On BIG-IP versions 16.0.x before 16.0.1.1, 15.1.x before 15.1.2.1, 14.1.x before 14.1.4, 13.1.x before 13.1.3.6, and 12.
Local privilege escalation and information disclosure in the Linux kernel on AMD Zen2 CPUs allows low-privileged users t
An exploitable code execution vulnerability exists in the Shader functionality of AMD Radeon DirectX 11 Driver atidxx64.
An exploitable code execution vulnerability exists in the Shader functionality of AMD Radeon DirectX 11 Driver atidxx64.
An exploitable code execution vulnerability exists in the Shader functionality of AMD Radeon DirectX 11 Driver atidxx64.
An exploitable memory corruption vulnerability exists in AMD atidxx64.dll 26.20.15019.19000 graphics driver. Rated criti
plays_service.exe in the plays.tv service before 1.27.7.0, as distributed in AMD driver-installation packages and Gaming
A flaw was found in the KVM's AMD code for supporting SVM nested virtualization. Rated high severity (CVSS 8.8), this vu
AMD ATI atillk64.sys 5.11.9.0 allows low-privileged users to interact directly with physical memory by calling one of se
An exploitable out-of-bounds read vulnerability exists in AMD ATIDXX64.DLL driver, version 26.20.13001.29010. Rated high
AMD fglrx-driver before 15.9 allows local users to gain privileges via a symlink attack. Rated high severity (CVSS 7.8),
AMD fglrx-driver before 15.7 allows local users to gain privileges via a symlink attack. Rated high severity (CVSS 7.8),
Exploit-DB