CVE-2026-89815: drm/ttm: Drop tt->restore after successful restore
In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: Drop tt->restore after successful restore
ttmpoolrestoreandalloc() can successfully complete the restore process via ttmpoolrestorecommit(), but tt->restore is not dropped afterward. As a result, subsequent backup/restore flows observe what appears to be a completed restore, while in reality shmem handles are still installed in tt->pages, leading to the stack trace below.
Fix this by freeing and dropping tt->restore in ttmpoolrestoreandalloc() upon successful completion of the restore.
20545 [ 309.784531] RIP: 0010:sgallocappendtablefrompages+0x38c/0x490 20547 [ 309.809570] RSP: 0018:ffffc9000623b838 EFLAGS: 00010206 20548 [ 309.814827] RAX: 0000000000001000 RBX: ffff88816e42a160 RCX: 0000000000000000 20549 [ 309.821986] RDX: 0000000000002000 RSI: 0000000000000003 RDI: 0000000000001000 20550 [ 309.829147] RBP: ffff88816e42a168 R08: 0000000000000002 R09: 000000007ffff000 20551 [ 309.836310] R10: ffffc9000623b928 R11: 0000000000000000 R12: 000000007ffff000 20552 [ 309.843471] R13: ffff88815ba5a100 R14: 0000000000000000 R15: 0000000000000001 20553 [ 309.850634] FS: 00007f9ff305e700(0000) GS:ffff888276c94000(0000) knlGS:0000000000000000 20554 [ 309.858749] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 20555 [ 309.864519] CR2: 00007f9fca701000 CR3: 00000001565e2005 CR4: 0000000008f70ef0 20556 [ 309.871678] PKRU: 55555558 20557 [ 309.874403] Call Trace: 20558 [ 309.876866] <TASK> 20559 [ 309.878988] sgalloctablefrompagessegment+0x60/0x100 20560 [ 309.884415] ? ttmresourcemanagerusage+0x36/0x60 [ttm] 20561 [ 309.889845] ? xettmapsg+0x7d/0xd0 [xe] 20562 [ 309.894045] xettmapsg+0x7d/0xd0 [xe] 20563 [ 309.898037] xebomove+0x927/0xaa0 [xe] 20564 [ 309.902029] ttmbohandlemovemem+0xba/0x170 [ttm] 20565 [ 309.907022] ttmbovalidate+0xbe/0x190 [ttm] 20566 [ 309.911405] xebovalidate+0x9a/0x120 [xe] 20567 [ 309.915663] xegpuvmvalidate+0xd9/0x140 [xe] 20568 [ 309.920206] drmgpuvmvalidate+0x2f0/0x5b0 [drmgpuvm] 20569 [ 309.925459] ? drmexeclockobj+0x63/0x210 [drmexec] 20570 [ 309.930627] xevmvalidaterebind+0x46/0xb0 [xe] 20571 [ 309.935428] xeexecfn+0x20/0x40 [xe] 20572 [ 309.939249] drmgpuvmexeclock+0x78/0xc0 [drmgpuvm] 20573 [ 309.944410] xevalidationexeclock+0x5a/0xa0 [xe] 20574 [ 309.949385] xeexecioctl+0x806/0xc30 [xe] 20575 [ 309.953639] ? ttwuqueuewakelist+0xd9/0xf0 20576 [ 309.957935] ? pfxxeexecfn+0x10/0x10 [xe] 20577 [ 309.962449] ? wakeupcommon+0x73/0xa0 20578 [ 309.966482] ? pfxxeexecioctl+0x10/0x10 [xe] 20579 [ 309.971263] drmioctlkernel+0xa3/0x100 20580 [ 309.975209] drmioctl+0x213/0x440 20581 [ 309.978637] ? pfxxeexecioctl+0x10/0x10 [xe] 20582 [ 309.983415] xedrmioctl+0x67/0xd0 [xe] 20583 [ 309.987408] x64sysioctl+0x7f/0xd0
Affected Software
Event History
Frequently Asked Questions
What systems are realistically exposed to this issue?
Systems running the Linux kernel and using the DRM TTM memory-management path are the relevant population. The failure is associated with subsequent TTM backup/restore flows after a restore has completed.
What condition is needed to trigger the failure?
A successful restore through ttm_pool_restore_commit() must occur, followed by another backup/restore flow. The stale tt->restore state can then cause the later flow to operate while shmem handles remain installed in tt->pages.
How can administrators tell whether they may already be affected?
The supplied evidence is a kernel stack trace involving sg_alloc_append_table_from_pages. Reviewing kernel crash logs for that function in conjunction with DRM TTM backup/restore activity may indicate exposure, but the data does not provide a definitive detection method.
What change resolves the issue?
The fix frees and drops tt->restore in ttm_pool_restore_and_alloc() after restore completion succeeds. The provided references identify stable-kernel commits containing the correction.