CVE-2026-31479

*** 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&amp;#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)