GPU VulnDB

Database/NVIDIA / GPU stack

Linux drm/ttm: swapped-out resources stay in their bulk_move range, leaving a dangling cursor (use-after-free)

UnscoredCVE-2026-98166NVIDIA / GPU stackcurated

Impact

A regression in TTM's swapout path meant the bulk_move bookkeeping was skipped on every successful swapout, so a swapped-out GPU resource stayed inside its buffer object's bulk_move range. When that resource is later freed or the BO leaves the range, a range endpoint is left pointing at freed memory and the next bulk-move operation is a use-after-free - observed as list corruption or a NULL dereference minutes to hours later, at process exit or reboot. On a GPU node this is a memory-corruption crash in the graphics memory manager shared by amdgpu, so it is a stability and potentially exploitable-corruption issue in a kernel path any local GPU workload can drive through memory pressure. The reporter reproduced it through hibernation cycles on a consumer APU; datacenter nodes do not usually hibernate, which makes the swapout pressure needed to reach it less common but not absent.

Who can reach it

Local only. A user with access to a GPU device node whose workload drives TTM into swapping out buffer objects; no network path and no authentication boundary is crossed. Reachable only on hosts running a TTM-based GPU driver, which on a GPU fleet means amdgpu.

What to do

Fixed in stable by testing for success correctly in ttm_bo_swapout_cb(); take the stable kernel carrying commit 1169fe8c11ca / 3db7d7d583419. Applying it means a kernel update and a reboot of each node, so drain the node first - the driver module cannot be reloaded safely under live GPU workloads.

References

Related entries

All NVIDIA / GPU stack entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.