drm/ttm: stale restore state after a successful restore leaves shmem handles in the page array

CVSS 7.8CVE-2026-89815NVIDIA / GPU stackcurated

Impact

ttm_pool_restore_and_alloc() can finish a restore successfully but never drops tt->restore. Later backup/restore flows then see a restore that looks already complete while shmem handles are still installed in tt->pages, and the pages get handed to the scatter-gather builder as if they were real pages - the reported trace crashes in sg_alloc_append_table_from_pages() by way of xe_tt_map_sg() during a Xe exec ioctl. TTM backup/restore is what backs GPU memory eviction and suspend on Xe and other TTM drivers, so on a busy node this is reached by ordinary memory pressure rather than by a crafted request. The immediate consequence in the record is a kernel oops on the submit path, which takes down every workload on that GPU.

Who can reach it

Local. Any tenant submitting GPU work through a TTM-backed driver (the trace is Xe's exec ioctl) on a node under enough memory pressure to evict and restore buffer objects. No elevated privilege.

What to do

Take the stable-kernel update that frees and clears tt->restore once ttm_pool_restore_commit() succeeds. TTM is in the kernel tree, so this is a kernel upgrade: drain GPU jobs and reboot the node. No userspace or daemon-level workaround; reducing memory pressure only makes the path rarer.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-89815 https://git.kernel.org/stable/c/941ac10529b3be5965a88d432a161ab459672ba8 https://git.kernel.org/stable/c/a46ab76b6cf5478e2ac7b942a377c7a1827b436a

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.