CVE-2026-31479
Fecha de publicación:
22/04/2026
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
drm/xe: always keep track of remap prev/next<br />
<br />
During 3D workload, user is reporting hitting:<br />
<br />
[ 413.361679] WARNING: drivers/gpu/drm/xe/xe_vm.c:1217 at vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe], CPU#7: vkd3d_queue/9925<br />
[ 413.361944] CPU: 7 UID: 1000 PID: 9925 Comm: vkd3d_queue Kdump: loaded Not tainted 7.0.0-070000rc3-generic #202603090038 PREEMPT(lazy)<br />
[ 413.361949] RIP: 0010:vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe]<br />
[ 413.362074] RSP: 0018:ffffd4c25c3df930 EFLAGS: 00010282<br />
[ 413.362077] RAX: 0000000000000000 RBX: ffff8f3ee817ed10 RCX: 0000000000000000<br />
[ 413.362078] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br />
[ 413.362079] RBP: ffffd4c25c3df980 R08: 0000000000000000 R09: 0000000000000000<br />
[ 413.362081] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8f41fbf99380<br />
[ 413.362082] R13: ffff8f3ee817e968 R14: 00000000ffffffef R15: ffff8f43d00bd380<br />
[ 413.362083] FS: 00000001040ff6c0(0000) GS:ffff8f4696d89000(0000) knlGS:00000000330b0000<br />
[ 413.362085] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033<br />
[ 413.362086] CR2: 00007ddfc4747000 CR3: 00000002e6262005 CR4: 0000000000f72ef0<br />
[ 413.362088] PKRU: 55555554<br />
[ 413.362089] Call Trace:<br />
[ 413.362092] <br />
[ 413.362096] xe_vm_bind_ioctl+0xa9a/0xc60 [xe]<br />
<br />
Which seems to hint that the vma we are re-inserting for the ops unwind<br />
is either invalid or overlapping with something already inserted in the<br />
vm. It shouldn&#39;t be invalid since this is a re-insertion, so must have<br />
worked before. Leaving the likely culprit as something already placed<br />
where we want to insert the vma.<br />
<br />
Following from that, for the case where we do something like a rebind in<br />
the middle of a vma, and one or both mapped ends are already compatible,<br />
we skip doing the rebind of those vma and set next/prev to NULL. As well<br />
as then adjust the original unmap va range, to avoid unmapping the ends.<br />
However, if we trigger the unwind path, we end up with three va, with<br />
the two ends never being removed and the original va range in the middle<br />
still being the shrunken size.<br />
<br />
If this occurs, one failure mode is when another unwind op needs to<br />
interact with that range, which can happen with a vector of binds. For<br />
example, if we need to re-insert something in place of the original va.<br />
In this case the va is still the shrunken version, so when removing it<br />
and then doing a re-insert it can overlap with the ends, which were<br />
never removed, triggering a warning like above, plus leaving the vm in a<br />
bad state.<br />
<br />
With that, we need two things here:<br />
<br />
1) Stop nuking the prev/next tracking for the skip cases. Instead<br />
relying on checking for skip prev/next, where needed. That way on the<br />
unwind path, we now correctly remove both ends.<br />
<br />
2) Undo the unmap va shrinkage, on the unwind path. With the two ends<br />
now removed the unmap va should expand back to the original size again,<br />
before re-insertion.<br />
<br />
v2:<br />
- Update the explanation in the commit message, based on an actual IGT of<br />
triggering this issue, rather than conjecture.<br />
- Also undo the unmap shrinkage, for the skip case. With the two ends<br />
now removed, the original unmap va range should expand back to the<br />
original range.<br />
v3:<br />
- Track the old start/range separately. vma_size/start() uses the va<br />
info directly.<br />
<br />
(cherry picked from commit aec6969f75afbf4e01fd5fb5850ed3e9c27043ac)
Gravedad: Pendiente de análisis
Última modificación:
23/04/2026