Description
In the Linux kernel, the following vulnerability has been resolved:

drm/xe: always keep track of remap prev/next

During 3D workload, user is reporting hitting:

[ 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
[ 413.361944] CPU: 7 UID: 1000 PID: 9925 Comm: vkd3d_queue Kdump: loaded Not tainted 7.0.0-070000rc3-generic #202603090038 PREEMPT(lazy)
[ 413.361949] RIP: 0010:vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe]
[ 413.362074] RSP: 0018:ffffd4c25c3df930 EFLAGS: 00010282
[ 413.362077] RAX: 0000000000000000 RBX: ffff8f3ee817ed10 RCX: 0000000000000000
[ 413.362078] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 413.362079] RBP: ffffd4c25c3df980 R08: 0000000000000000 R09: 0000000000000000
[ 413.362081] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8f41fbf99380
[ 413.362082] R13: ffff8f3ee817e968 R14: 00000000ffffffef R15: ffff8f43d00bd380
[ 413.362083] FS: 00000001040ff6c0(0000) GS:ffff8f4696d89000(0000) knlGS:00000000330b0000
[ 413.362085] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
[ 413.362086] CR2: 00007ddfc4747000 CR3: 00000002e6262005 CR4: 0000000000f72ef0
[ 413.362088] PKRU: 55555554
[ 413.362089] Call Trace:
[ 413.362092] <TASK>
[ 413.362096] xe_vm_bind_ioctl+0xa9a/0xc60 [xe]

Which seems to hint that the vma we are re-inserting for the ops unwind
is either invalid or overlapping with something already inserted in the
vm. It shouldn't be invalid since this is a re-insertion, so must have
worked before. Leaving the likely culprit as something already placed
where we want to insert the vma.

Following from that, for the case where we do something like a rebind in
the middle of a vma, and one or both mapped ends are already compatible,
we skip doing the rebind of those vma and set next/prev to NULL. As well
as then adjust the original unmap va range, to avoid unmapping the ends.
However, if we trigger the unwind path, we end up with three va, with
the two ends never being removed and the original va range in the middle
still being the shrunken size.

If this occurs, one failure mode is when another unwind op needs to
interact with that range, which can happen with a vector of binds. For
example, if we need to re-insert something in place of the original va.
In this case the va is still the shrunken version, so when removing it
and then doing a re-insert it can overlap with the ends, which were
never removed, triggering a warning like above, plus leaving the vm in a
bad state.

With that, we need two things here:

1) Stop nuking the prev/next tracking for the skip cases. Instead
relying on checking for skip prev/next, where needed. That way on the
unwind path, we now correctly remove both ends.

2) Undo the unmap va shrinkage, on the unwind path. With the two ends
now removed the unmap va should expand back to the original size again,
before re-insertion.

v2:
- Update the explanation in the commit message, based on an actual IGT of
triggering this issue, rather than conjecture.
- Also undo the unmap shrinkage, for the skip case. With the two ends
now removed, the original unmap va range should expand back to the
original range.
v3:
- Track the old start/range separately. vma_size/start() uses the va
info directly.

(cherry picked from commit aec6969f75afbf4e01fd5fb5850ed3e9c27043ac)
Published: 2026-04-22
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service
Action: Patch
AI Analysis

Impact

The bug resides in the Linux kernel's DRM/xe driver where the logic that tracks the previous and next virtual memory areas (VMA) during remapping operations is incorrectly reset in certain skip scenarios. This oversight can create stale or overlapping VMA entries, leading to kernel warnings such as vm_bind_ioctl_ops_unwind and a corrupted VM state. Based on the description, it is inferred that the fault could lead to a kernel crash. The weakness manifests as improper memory management, resembling a use‑after‑free or buffer overflow (CWE‑823). Based on the description, it is inferred that such a fault can cause a system crash or abort, resulting in denial of service at the kernel level.

Affected Systems

All Linux kernel releases that include the drm/xe driver are affected. The bug is present in mainline kernels from 6.8 and any 7.0 release candidates up to rc7, as indicated by the CPE list and the reference kernel version 7.0.0-070000rc3-generic shown in the advisory. Any system running one of these kernel versions with the DRM/xe driver enabled is potentially vulnerable until the patch commit aec6969f75a… is applied.

Risk and Exploitability

The CVSS score is 7.8, indicating high severity, while the EPSS score is less than 1%, indicating a low likelihood of recent exploitation. The vulnerability is not listed in the CISA KEV catalog. Based on the description, it is inferred that exploitation would require local execution with access to the GPU driver; an unprivileged user on a system allowing 3D workloads could trigger the faulty VMA remap by running a graphics application. If a system runs an unpatched kernel with drm/xe enabled, it is inferred that a local attacker could exploit this defect to crash the system and cause a denial of service. The attack surface appears to be limited to environments where the buggy driver path is exercised.

Generated by OpenCVE AI on April 29, 2026 at 00:08 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the kernel to a version that includes the drm/xe fix (commit aec6969f75a…)
  • If an upgrade is not immediately possible, disable or uninstall the drm/xe driver or restrict GPU usage to prevent the buggy code path from executing
  • Monitor kernel logs for the warning pattern `vm_bind_ioctl_ops_unwind` and address any occurrences using patches or by limiting 3D workloads until a patch is applied

Generated by OpenCVE AI on April 29, 2026 at 00:08 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DSA Debian DSA DSA-6238-1 linux security update
History

Tue, 28 Apr 2026 21:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119
CWE-416

Mon, 27 Apr 2026 23:30:00 +0000

Type Values Removed Values Added
Weaknesses NVD-CWE-noinfo
CPEs cpe:2.3:o:linux:linux_kernel:6.8:-:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc7:*:*:*:*:*:*

Mon, 27 Apr 2026 19:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119
CWE-416

Mon, 27 Apr 2026 15:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

 cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

Thu, 23 Apr 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-823
References
Metrics threat_severity

None

 cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate

Wed, 22 Apr 2026 14:15:00 +0000

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

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-11T22:09:31.845Z

Reserved: 2026-03-09T15:48:24.100Z

Link: CVE-2026-31479

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2026-04-22T14:16:44.993

Modified: 2026-04-27T23:19:30.590

Link: CVE-2026-31479

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-04-22T00:00:00Z

Links: CVE-2026-31479 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-04-29T00:15:43Z

Weaknesses