CVE-2026-89967

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 OOB write is in migrate_device_range()/migrate_device_pfns() on the device-private eviction path, reached from local HMM/GPU SVM (close of /dev/hmm_dmirror*, Nouveau dmem teardown, Intel Xe drm_pagemap_evict_to_ram after DRM_XE_VM_BIND), not from received network packets.

AC:LAttack complexity, low

The attacker creates a compound device folio by migrating an anonymous THP or huge-zero page, then triggers eviction of a too-small PFN array (dmirror close/HMM_DMIRROR_RELEASE or Xe TTM eviction of a CPU_ADDR_MIRROR BO). The HMM selftest hits this deterministically; no victim timing is required.

PR:LPrivileges required, low

Intel Xe DRM_XE_VM_BIND is DRM_RENDER_ALLOW with no capable() or DRM-master check. An unprivileged local user with typical render/video-group access to /dev/dri/renderD* can migrate a THP to device memory and force drm_pagemap_evict_to_ram.

UI:NUser interaction, none

The attacker performs mmap/madvise, the migrate ioctl, and eviction or close entirely in their own process. No other user or administrator needs to mount a filesystem, open a file, or otherwise interact.

S:UScope, unchanged

The overflow corrupts host-kernel memory adjacent to the caller-provided src_pfns kvcalloc/kvmalloc array. That is standard local privilege escalation in the same security authority, not a KVM/Xen guest-to-host escape or IOMMU/DMA bypass.

C:HConfidentiality impact, high

migrate_device_* zeros every tail slot of a compound folio without clipping to npages, overflowing the PFN array by up to (folio_nr_pages-remaining) pointers (~4KB for a 2MB THP). That heap corruption can be turned into an arbitrary kernel read via overlapping objects.

I:HIntegrity impact, high

The same unbounded store is an out-of-bounds kernel write into adjacent slab/vmalloc objects. Zeroing neighboring heap metadata, pointers, or function pointers is exploitable for an arbitrary write and control-flow hijack, not a bounded integrity change.

A:HAvailability impact, high

KASAN reports this overflow on the HMM migrate_anon_huge_zero selftest when closing /dev/hmm_dmirror0, and smashing adjacent kernel objects with zeros causes an oops or panic even without a completed exploit.