CVE-2026-93284

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

Local ioctl/fault path only: DRM_IOCTL_XE_VM_CREATE (FAULT_MODE) and DRM_IOCTL_XE_VM_BIND (CPU_ADDR_MIRROR) on /dev/dri/renderD* migrate the caller's anonymous range to VRAM, then do_swap_page() invokes drm_pagemap_migrate_to_ram() -> __drm_pagemap_migrate_to_ram(), or xe_bo_move() calls xe_svm_bo_evict() -> drm_pagemap_evict_to_ram(). No remote protocol byte reaches those functions.

AC:LAttack complexity, low

The attacker creates the SVM range, migrates it to VRAM, and CPU-faults or TTM-evicts it. After drm_pagemap_migrate_map_system_pages() has dma_map_page()'d dest folios, they force err_finalize by exhausting gt->usm.bb_pool so xe_svm_copy_to_ram()/xe_bb_new() returns -ENOMEM, or by fragmenting IOVA so dma_iova_try_alloc() fails and a later dma_map_page() returns -EFAULT. No victim timing.

PR:LPrivileges required, low

DRM_IOCTL_XE_VM_CREATE and DRM_IOCTL_XE_VM_BIND are DRM_RENDER_ALLOW; xe_vm_create_ioctl() performs no capable() or DRM-master check. An unprivileged local user with typical render/video-group access to /dev/dri/renderD* on an Intel Xe discrete GPU (CONFIG_DRM_XE_PAGEMAP defaults to y) can create a fault-mode VM and reach the patched functions.

UI:NUser interaction, none

The attacking process opens the render node, creates its own fault-mode VM, CPU_ADDR_MIRROR-binds its anonymous mapping, prefetches or GPU-faults it into VRAM, then CPU-accesses or forces TTM eviction. No other user must mount a filesystem or open a file.

S:CScope, changed

On err_finalize, drm_pagemap_migration_unlock_put_pages() folio_put()s the destination RAM folios and zeros migrate_pfn, so drm_pagemap_migrate_unmap_pages() sees a NULL page and skips dma_unmap_page(). Those IOMMU PTEs remain aimed at pages already returned to the buddy allocator, which is an IOMMU/DMA isolation bypass.

C:HConfidentiality impact, high

Destination folios from drm_pagemap_migrate_populate_ram_pfn() are put while still dma_map_page()'d. Recycled host pages stay IOMMU-reachable through the leaked translation, so later DMA can disclose their new kernel or cross-process contents rather than a bounded pointer leak.

I:HIntegrity impact, high

The leaked mappings are DMA_FROM_DEVICE (Xe copy-from-VRAM via xe_svm_copy_to_ram()). After folio_put(), a GPU/IOMMU transaction through those IOVAs writes into whatever reused the physical pages, an arbitrary physical write through the IOMMU rather than a bounded corruption.

A:HAvailability impact, high

Each failed __drm_pagemap_migrate_to_ram()/drm_pagemap_evict_to_ram() leaks that range's dma_map_page() IOVAs; the attacker loops CPU faults after inducing xe_bb_new() or map errors. Unbounded IOVA growth wedges later maps, and DMA into buddy-reused pages oopses or panics, not a mere slowdown.