CVE-2026-74716 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: Fix locally exploitable BUG_ON in amdxdna_insert_pages()
In amdxdna_insert_pages(), vm_flags_mod() sets VM_MIXEDMAP and clears VM_PFNMAP. If an unprivileged userspace process mmaps a non-imported GEM object and then calls madvise(MADV_DONTNEED), the PTEs will be successfully cleared because VM_MIXEDMAP allows this (unlike VM_PFNMAP).
When userspace subsequently accesses the memory, drm_gem_shmem_fault() handles the page fault and attempts to map the backing shmem page via vmf_insert_pfn() which calls vmf_insert_pfn_prot(). Because the backing shmem page is normal system memory (pfn_valid(pfn) is true) and the VMA now has VM_MIXEDMAP set, won't this predictably trigger the explicit assertion BUG_ON((vma->vm_flags & VM_MIXEDMAP) && pfn_valid(pfn))
Fix by removing the vm_flags_mod() call and replacing the vm_insert_pages() pre-population with the handle_mm_fault() loop that was already used for the import (dma-buf) path.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The vulnerability identified in the Linux kernel's AMD XDNA driver, specifically within the amdxdna_insert_pages function, represents a critical local privilege escalation risk stemming from improper memory management flag handling during device buffer mapping operations. The core technical flaw lies in the sequence of virtual memory area (VMA) flags modification where vm_flags_mod is invoked to set VM_MIXEDMAP while simultaneously clearing VM_PFNMAP. This configuration creates a dangerous state when interacting with non-imported Graphics Execution Manager objects, as it alters how the kernel interprets and manages page table entries for user-space mapped regions. Under normal circumstances, certain memory mappings are restricted from being modified by standard userspace madvise operations to prevent unauthorized manipulation of hardware-accessible memory structures. However, the presence of VM_MIXEDMAP in this specific context inadvertently permits these modifications, bypassing intended security controls that rely on stricter mapping types like VM_PFNMAP which would reject such attempts at page table modification.
The operational impact manifests when an unprivileged userspace process maps a non-imported GEM object and subsequently invokes madvise with the MADV_DONTNEED flag. This system call successfully clears the corresponding Page Table Entries, effectively removing the physical memory mappings from the kernel's view while leaving the virtual address space intact but unmapped. When the application later attempts to access this memory region, a page fault is triggered and handled by drm_gem_shmem_fault. The handler proceeds to map the backing shared memory page using vmf_insert_pfn, which internally calls vmf_insert_pfn_prot. At this juncture, the kernel encounters a contradiction: it detects that the VMA possesses VM_MIXEDMAP flags indicating mixed mapping capabilities, yet the physical frame number being inserted corresponds to valid system memory where pfn_valid returns true. This specific combination triggers an explicit BUG_ON assertion within the kernel code, resulting in a local denial of service through kernel panic or crash.
From a classification perspective, this vulnerability aligns with CWE-253 Incorrect Check of Function Return Value and CWE-787 Out-of-bounds Write if the bug leads to memory corruption, though primarily it is categorized under improper input validation leading to assertion failures that compromise system stability. In terms of adversarial tactics, this flaw facilitates Local Privilege Escalation via Denial of Service as defined in MITRE ATT&CK technique T1055 or more specifically T1499 Endpoint Denial of Service if the crash is leveraged for disruption, though typically such kernel bugs are exploited to gain code execution through use-after-free scenarios that may arise from the inconsistent state. The vulnerability highlights the complexity of managing memory mappings in high-performance computing drivers where hardware requirements often conflict with standard Linux virtual memory management policies.
The resolution involves removing the problematic vm_flags_mod call and replacing the pre-population logic using vm_insert_pages with a handle_mm_fault loop, mirroring the approach already established for the dma-buf import path. This change ensures that page faults are handled consistently regardless of whether the buffer was imported or locally allocated, thereby preventing the inconsistent state that leads to the assertion failure. Mitigation strategies include applying the upstream kernel patch immediately upon availability and ensuring that systems running affected versions do not expose AMD XDNA devices to untrusted userspace processes without strict access controls. Administrators should also monitor for unusual system crashes related to GPU drivers as an indicator of potential exploitation attempts, although direct code execution from this specific bug is less likely than the denial of service outcome unless further memory corruption issues exist in adjacent code paths.