CVE-2026-68240

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 vulnerable code is reached only through local Intel Xe DRM render-node operations on /dev/dri/renderD* — DRM_XE_VM_CREATE in fault mode, VM_BIND of a CPU_ADDR_MIRROR range, madvise/prefetch to place pages in device VRAM, and a GPU exec that faults into __xe_svm_handle_pagefault(). No network or remote-peer input reaches drm_gpusvm_get_pages().

AC:LAttack complexity, low

The attacker deterministically controls both preconditions: it chooses which pages of its own range live in device-private VRAM versus system memory, so the `!ctx->allow_mixed` / second-pagemap check fires at err_unmap after the first device page has already been device_map()'d. No race, no memory-layout grooming, and __xe_svm_handle_pagefault() loops on `goto retry`, replaying the leak on demand.

PR:LPrivileges required, low

Every ioctl on the path is DRM_RENDER_ALLOW; xe_vm_create_ioctl(), VM_BIND and exec perform no capable() or DRM-master check. Any unprivileged local user holding a render-node fd — the default for desktop seat users, render/video group members, containers and cloud GPU instances with /dev/dri passed through — can reach it.

UI:NUser interaction, none

The attacking process performs the entire sequence with its own ioctls, its own mappings and its own GPU submissions; the failing get_pages call is triggered by its own page fault. No action by another user or administrator is required.

S:CScope, changed

__drm_gpusvm_unmap_pages() is documented as the enforcement point of the GPU SVM IOMMU security model, and skipping device_unmap() leaves dma_map_resource() P2P translations programmed in the IOMMU after the range and its owning context are gone. The device keeps DMA reach into memory the DMA-isolation authority was supposed to withhold from it, crossing the IOMMU/DMA boundary.

C:HConfidentiality impact, high

The leaked mappings are live IOMMU windows onto a peer GPU's VRAM BAR that outlive the SVM range and the process, so device memory subsequently reallocated to other DRM clients remains readable through the stale translation rather than being revoked at teardown, which is exactly what the missing device_unmap() was supposed to prevent.

I:HIntegrity impact, high

The leaked device mappings are created with dma_dir = DMA_BIDIRECTIONAL whenever the VMA is not read-only, so the stale window is device-writable as well as readable, leaving an attacker-influenced DMA write path into peer device memory that has since been handed to another context.

A:HAvailability impact, high

Each failed get_pages leaks IOVA space and IOMMU page-table memory with no bound, and __xe_svm_handle_pagefault() re-enters `goto retry` while holding vm->lock for write, so an unprivileged loop rapidly exhausts the device's IOVA/DMA resources and makes subsequent dma_map_resource()/dma_map_page() calls fail system-wide, hanging or wedging GPU clients on the machine.