{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-89815","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","state":"PUBLISHED","assignerShortName":"Linux","dateReserved":"2026-09-11T19:38:34.768Z","datePublished":"2026-09-16T10:30:48.133Z","dateUpdated":"2026-09-21T13:15:05.305Z"},"containers":{"cna":{"providerMetadata":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-09-21T13:15:05.305Z"},"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/ttm: Drop tt->restore after successful restore\n\nttm_pool_restore_and_alloc() can successfully complete the restore\nprocess via ttm_pool_restore_commit(), but tt->restore is not dropped\nafterward. As a result, subsequent backup/restore flows observe what\nappears to be a completed restore, while in reality shmem handles are\nstill installed in tt->pages, leading to the stack trace below.\n\nFix this by freeing and dropping tt->restore in\nttm_pool_restore_and_alloc() upon successful completion of the restore.\n\n20545 [  309.784531] RIP: 0010:sg_alloc_append_table_from_pages+0x38c/0x490\n20547 [  309.809570] RSP: 0018:ffffc9000623b838 EFLAGS: 00010206\n20548 [  309.814827] RAX: 0000000000001000 RBX: ffff88816e42a160 RCX: 0000000000000000\n20549 [  309.821986] RDX: 0000000000002000 RSI: 0000000000000003 RDI: 0000000000001000\n20550 [  309.829147] RBP: ffff88816e42a168 R08: 0000000000000002 R09: 000000007ffff000\n20551 [  309.836310] R10: ffffc9000623b928 R11: 0000000000000000 R12: 000000007ffff000\n20552 [  309.843471] R13: ffff88815ba5a100 R14: 0000000000000000 R15: 0000000000000001\n20553 [  309.850634] FS:  00007f9ff305e700(0000) GS:ffff888276c94000(0000) knlGS:0000000000000000\n20554 [  309.858749] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n20555 [  309.864519] CR2: 00007f9fca701000 CR3: 00000001565e2005 CR4: 0000000008f70ef0\n20556 [  309.871678] PKRU: 55555558\n20557 [  309.874403] Call Trace:\n20558 [  309.876866]  <TASK>\n20559 [  309.878988]  sg_alloc_table_from_pages_segment+0x60/0x100\n20560 [  309.884415]  ? ttm_resource_manager_usage+0x36/0x60 [ttm]\n20561 [  309.889845]  ? xe_tt_map_sg+0x7d/0xd0 [xe]\n20562 [  309.894045]  xe_tt_map_sg+0x7d/0xd0 [xe]\n20563 [  309.898037]  xe_bo_move+0x927/0xaa0 [xe]\n20564 [  309.902029]  ttm_bo_handle_move_mem+0xba/0x170 [ttm]\n20565 [  309.907022]  ttm_bo_validate+0xbe/0x190 [ttm]\n20566 [  309.911405]  xe_bo_validate+0x9a/0x120 [xe]\n20567 [  309.915663]  xe_gpuvm_validate+0xd9/0x140 [xe]\n20568 [  309.920206]  drm_gpuvm_validate+0x2f0/0x5b0 [drm_gpuvm]\n20569 [  309.925459]  ? drm_exec_lock_obj+0x63/0x210 [drm_exec]\n20570 [  309.930627]  xe_vm_validate_rebind+0x46/0xb0 [xe]\n20571 [  309.935428]  xe_exec_fn+0x20/0x40 [xe]\n20572 [  309.939249]  drm_gpuvm_exec_lock+0x78/0xc0 [drm_gpuvm]\n20573 [  309.944410]  xe_validation_exec_lock+0x5a/0xa0 [xe]\n20574 [  309.949385]  xe_exec_ioctl+0x806/0xc30 [xe]\n20575 [  309.953639]  ? ttwu_queue_wakelist+0xd9/0xf0\n20576 [  309.957935]  ? __pfx_xe_exec_fn+0x10/0x10 [xe]\n20577 [  309.962449]  ? __wake_up_common+0x73/0xa0\n20578 [  309.966482]  ? __pfx_xe_exec_ioctl+0x10/0x10 [xe]\n20579 [  309.971263]  drm_ioctl_kernel+0xa3/0x100\n20580 [  309.975209]  drm_ioctl+0x213/0x440\n20581 [  309.978637]  ? __pfx_xe_exec_ioctl+0x10/0x10 [xe]\n20582 [  309.983415]  xe_drm_ioctl+0x67/0xd0 [xe]\n20583 [  309.987408]  __x64_sys_ioctl+0x7f/0xd0"}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH"},"scenarios":[{"lang":"en","value":"AV:L - The bug is reached only via local DRM ioctls on a TTM GPU (Intel Xe xe_exec_ioctl -> xe_bo_validate -> ttm_bo_validate -> ttm_tt_restore -> ttm_pool_restore_and_alloc). It is not reachable from network packets, Bluetooth/Wi-Fi frames, or USB.\nAC:L - An attacker can create shrinkable GPU BOs, induce reclaim so the Xe shrinker backs them up to shmem, then retry exec/validate to resume restore and later backup/restore again. Both sides of the backup/restore sequence are attacker-driven and retryable; no victim-only timing or rare non-default config is required.\nPR:L - xe_exec_ioctl, GEM create, and VM bind are DRM_RENDER_ALLOW with no CAP_SYS_ADMIN or DRM-master check. An unprivileged local user with typical render/video-group access to /dev/dri/renderD* on Xe systems can open the render node and exercise this path.\nUI:N - The attacker opens the render node, creates BOs, and issues exec/validate ioctls in their own process. No separate victim action such as mounting a filesystem or opening a file is required.\nS:U - Impact stays in the host kernel TTM/DRM authority (bogus page pointers used for SG/DMA and page-fault mapping). This is not a guest-to-host, IOMMU, or sandbox boundary escape.\nC:H - After a successful resumed restore, tt->restore is left set so a later backup/restore skips restore while shmem handles remain in tt->pages. Those handles are type-confused as struct page * in sg_alloc_append_table_from_pages, dma_map_sgtable, and ttm_bo_vm_fault page_to_pfn/vmf_insert_pfn, which can disclose kernel or physical memory.\nI:H - The same page-pointer type confusion feeds encoded shmem handles into scatter-gather DMA mapping and vmf_insert_pfn, which is memory corruption exploitable for arbitrary write or control-flow hijack rather than a pure crash.\nA:H - The reported oops is a kernel crash in sg_alloc_append_table_from_pages while walking the still-encoded handles as page pointers, which takes down the host."}]}],"affected":[{"product":"Linux","vendor":"Linux","defaultStatus":"unaffected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["drivers/gpu/drm/ttm/ttm_pool.c"],"versions":[{"version":"b63d715b8090aed48bdef5930625946fa4c0d324","lessThan":"329ddc5d438f991f49e4fd24c704d1c7288d5e03","status":"affected","versionType":"git"},{"version":"b63d715b8090aed48bdef5930625946fa4c0d324","lessThan":"a46ab76b6cf5478e2ac7b942a377c7a1827b436a","status":"affected","versionType":"git"},{"version":"b63d715b8090aed48bdef5930625946fa4c0d324","lessThan":"941ac10529b3be5965a88d432a161ab459672ba8","status":"affected","versionType":"git"}]},{"product":"Linux","vendor":"Linux","defaultStatus":"affected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["drivers/gpu/drm/ttm/ttm_pool.c"],"versions":[{"version":"6.15","status":"affected"},{"version":"0","lessThan":"6.15","status":"unaffected","versionType":"semver"},{"version":"6.18.53","lessThanOrEqual":"6.18.*","status":"unaffected","versionType":"semver"},{"version":"7.2.5","lessThanOrEqual":"7.2.*","status":"unaffected","versionType":"semver"},{"version":"7.3-rc1","lessThanOrEqual":"*","status":"unaffected","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.15","versionEndExcluding":"6.18.53"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.15","versionEndExcluding":"7.2.5"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.15","versionEndExcluding":"7.3-rc1"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/329ddc5d438f991f49e4fd24c704d1c7288d5e03"},{"url":"https://git.kernel.org/stable/c/a46ab76b6cf5478e2ac7b942a377c7a1827b436a"},{"url":"https://git.kernel.org/stable/c/941ac10529b3be5965a88d432a161ab459672ba8"}],"title":"drm/ttm: Drop tt->restore after successful restore","x_generator":{"engine":"bippy-1.2.0"}}}}