CVE-2026-74721 Overview
CVE-2026-74721 is a Linux kernel vulnerability in the accel/amxdna driver, which handles the AMD XDNA AI accelerator. The flaw resides in amdxdna_insert_pages(), where two error paths incorrectly invoke vma->vm_ops->close(vma) before returning an error. This premature close drops the shmem pages_pin_count and the Graphics Execution Manager (GEM) object reference backing the Virtual Memory Area (VMA) while the VMA remains live. When the process later unmaps the range, the kernel calls vm_ops->close() a second time, producing a reference count underflow.
Critical Impact
A local, low-privileged user with access to the AMD XDNA accelerator device can trigger reference count corruption in the kernel, leading to memory corruption and potential local privilege escalation.
Affected Products
- Linux kernel versions containing the accel/amdxdna driver prior to the fix commits
- Systems exposing the AMD XDNA AI accelerator via the accel subsystem
- Distributions shipping affected stable kernel branches referenced in the upstream fixes
Discovery Timeline
- 2026-08-22 - CVE-2026-74721 published to the National Vulnerability Database (NVD)
- 2026-08-25 - Last updated in NVD database
Technical Details for CVE-2026-74721
Vulnerability Analysis
The vulnerability is a reference counting error in the AMD XDNA accelerator driver's memory-mapping path. The function amdxdna_gem_obj_mmap() registers a Heterogeneous Memory Management (HMM) interval notifier before calling amdxdna_insert_pages(). On a hard error, it jumps to the hmm_unreg label to undo that registration.
Two error paths inside amdxdna_insert_pages() manually call vma->vm_ops->close(vma) before returning the error. That callback releases the shmem pages_pin_count and the GEM object reference associated with the VMA. However, the VMA itself remains valid because the mmap syscall has not yet returned to userspace.
When the process later unmaps the region, the kernel's standard VMA teardown invokes vm_ops->close() a second time on the same VMA. The double release produces a reference count underflow on the GEM object and on the shmem pin count, corrupting kernel state.
Root Cause
The root cause is incorrect cleanup ordering between the driver-level error path and kernel-managed VMA lifecycle. The driver assumed it owned VMA teardown on error, but the kernel core also runs vm_ops->close() during process exit or munmap(). This is a use-after-free style resource accounting error rather than a direct memory corruption primitive at the point of failure.
Attack Vector
A local attacker with permission to open the AMD XDNA accelerator character device can call mmap() under conditions that force amdxdna_insert_pages() down one of the two error paths. Triggering the error causes the premature vm_ops->close(), and subsequent teardown produces the reference count underflow. Repeated exploitation can be used to corrupt kernel object lifetimes and pursue local privilege escalation.
The upstream fix replaces both hard-error returns with a deferred-fault approach that keeps the VMA alive and retries page insertion through the HMM range-fault path. See the Kernel Git Commit 1501e4d and Kernel Git Commit 8d51e0f for the corrected logic.
Detection Methods for CVE-2026-74721
Indicators of Compromise
- Kernel log messages referencing refcount_t: underflow or WARNING traces originating from drm_gem_object_release or shmem pin accounting paths tied to the amdxdna driver.
- Unexpected kernel oops or BUG output following mmap() failures against the AMD XDNA accelerator device node.
- Processes repeatedly invoking mmap() on the accelerator device and observing EFAULT or similar failures immediately followed by kernel warnings.
Detection Strategies
- Monitor dmesg and /var/log/kern.log for reference count warnings and stack traces containing amdxdna_insert_pages or amdxdna_gem_obj_mmap.
- Enable kernel CONFIG_DEBUG_VM and refcount debugging in test environments to surface underflow events during triage.
- Correlate audit records of accelerator device access (/dev/accel/*) with subsequent kernel warning telemetry.
Monitoring Recommendations
- Forward kernel logs to a centralized analytics platform and alert on refcount underflow signatures.
- Track which non-root users hold open handles to accelerator device nodes on hosts running AMD XDNA hardware.
- Baseline normal accelerator workload behavior so that unusual mmap failure bursts are flagged for review.
How to Mitigate CVE-2026-74721
Immediate Actions Required
- Apply the upstream stable-tree fixes referenced in commits 1501e4d and 8d51e0f or upgrade to a distribution kernel that includes them.
- Restrict access to the AMD XDNA accelerator device nodes to trusted service accounts using file permissions and group ownership.
- Audit hosts with AMD XDNA hardware and prioritize patching where untrusted local users have shell access.
Patch Information
The fix replaces the two problematic hard-error returns in amdxdna_insert_pages() with a deferred-fault path that preserves VMA validity and retries page insertion through the HMM range-fault mechanism. Rebuild and deploy affected kernels from the fixed sources, or install vendor-provided kernel packages that incorporate Kernel Git Commit 1501e4d and Kernel Git Commit 8d51e0f.
Workarounds
- Unload the amdxdna kernel module on systems that do not require the AMD XDNA accelerator: modprobe -r amdxdna.
- Blacklist the module in /etc/modprobe.d/ to prevent automatic loading until a patched kernel is deployed.
- Remove access to /dev/accel/* device nodes for non-privileged users where accelerator workloads are not in production use.
# Configuration example
echo "blacklist amdxdna" | sudo tee /etc/modprobe.d/blacklist-amdxdna.conf
sudo modprobe -r amdxdna
sudo chmod 0660 /dev/accel/accel0
sudo chown root:accel-users /dev/accel/accel0
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

