Look up another CVE · open CVE-2026-89815 in the interactive tracker

CVE-2026-89815

drm/ttm: Drop tt->restore after successful restore

7.8 EPSS 0.2% AV:L

Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem drivers/gpu. Debian urgency: unimportant.

What to do, per Debian release

Debian's own status for CVE-2026-89815 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	not affected	6.1.190-1	Nothing to do. bookworm never shipped the vulnerable code.
Debian 13trixie	not affected	6.12.113-1	Nothing to do. trixie never shipped the vulnerable code.
Debian 14forky	fixed	7.2.6-1	Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.2.6-1	Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

ttm_pool_restore_and_alloc() can successfully complete the restore process via ttm_pool_restore_commit(), 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 ttm_pool_restore_and_alloc() upon successful completion of the restore. 20545 [ 309.784531] RIP: 0010:sg_alloc_append_table_from_pages+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] sg_alloc_table_from_pages_segment+0x60/0x100 20560 [ 309.884415] ? ttm_resource_manager_usage+0x36/0x60 [ttm] 20561 [ 309.889845] ? xe_tt_map_sg+0x7d/0xd0 [xe] 20562 [ 309.894045] xe_tt_map_sg+0x7d/0xd0 [xe] 20563 [ 309.898037] xe_bo_move+0x927/0xaa0 [xe] 20564 [ 309.902029] ttm_bo_handle_move_mem+0xba/0x170 [ttm] 20565 [ 309.907022] ttm_bo_validate+0xbe/0x190 [ttm] 20566 [ 309.911405] xe_bo_validate+0x9a/0x120 [xe] 20567 [ 309.915663] xe_gpuvm_validate+0xd9/0x140 [xe] 20568 [ 309.920206] drm_gpuvm_validate+0x2f0/0x5b0 [drm_gpuvm] 20569 [ 309.925459] ? drm_exec_lock_obj+0x63/0x210 [drm_exec] 20570 [ 309.930627] xe_vm_validate_rebind+0x46/0xb0 [xe] 20571 [ 309.935428] xe_exec_fn+0x20/0x40 [xe] 20572 [ 309.939249] drm_gpuvm_exec_lock+0x78/0xc0 [drm_gpuvm] 20573 [ 309.944410] xe_validation_exec_lock+0x5a/0xa0 [xe] 20574 [ 309.949385] xe_exec_ioctl+0x806/0xc30 [xe] 20575 [ 309.953639] ? ttwu_queue_wakelist+0xd9/0xf0 20576 [ 309.957935] ? __pfx_xe_exec_fn+0x10/0x10 [xe] 20577 [ 309.962449] ? __wake_up_common+0x73/0xa0 20578 [ 309.966482] ? __pfx_xe_exec_ioctl+0x10/0x10 [xe] 20579 [ 309.971263] drm_ioctl_kernel+0xa3/0x100 20580 [ 309.975209] drm_ioctl+0x213/0x440 20581 [ 309.978637] ? __pfx_xe_exec_ioctl+0x10/0x10 [xe] 20582 [ 309.983415] xe_drm_ioctl+0x67/0xd0 [xe] 20583 [ 309.987408] __x64_sys_ioctl+0x7f/0xd0

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/gpu/drm/ttm/ttm_pool.c

What this is: DRM TTM SUBSYSTEMMAINTAINERS section matched on drivers/gpu/drm/ttm/ · dri-devel@lists.freedesktop.org · Maintained
Kernel module: ttm

Check it on the machine

grep -w CONFIG_DRM_TTM /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w ttm

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, s390x/s390x
forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x

M: a module where it is built at all; some flavours do not build it

Build switch: CONFIG_DRM_TTM

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-09-16 (33 days ago)source
CVSS: 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: local (AV:L)source
EPSS: 0.17%, higher than 6.3% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: unimportantsource
Subsystem: drivers/gpu

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
6.15	6.18.53	329ddc5d438f
6.15	7.2.5	a46ab76b6cf5
6.15	7.3	941ac10529b3

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local: 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.
AC:LAttack complexity, low: 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.
PR:LPrivileges required, low: 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.
UI:NUser interaction, none: 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.
S:UScope, unchanged: 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.
C:HConfidentiality impact, high: 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.
I:HIntegrity impact, high: 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.
A:HAvailability impact, high: 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.