CVE-2026-74721: accel/amxdna: Fix page-insertion errors in amdxdna_insert_pages()
In the Linux kernel, the following vulnerability has been resolved:
accel/amxdna: Fix page-insertion errors in amdxdnainsertpages()
Two error paths in amdxdnainsertpages() called vma->vmops->close(vma) before returning an error code to the caller. This is incorrect: amdxdnagemobjmmap() registers an HMM interval notifier before calling amdxdnainsertpages(), and on a hard error it jumps to hmmunreg to undo that registration. Calling vmops->close() manually — which drops the shmem pagespincount and the GEM object reference that backs the VMA — before the mmap syscall has even returned causes those resources to be released while the VMA is still alive. The kernel VMA teardown will call vmops->close() a second time when the process later unmaps the range, producing a reference count underflow.
Replace both hard-error returns with a deferred-fault approach that keeps the VMA alive and retries page insertion through the HMM range-fault path.
Affected Software
Event History
Frequently Asked Questions
What conditions are needed to trigger the faulty error paths?
The issue is reached when amdxdna_insert_pages() encounters one of its hard error conditions during mmap setup after amdxdna_gem_obj_mmap() has registered an HMM interval notifier. The provided information does not identify the specific page-insertion failures that lead to those paths.
What is the practical consequence if the affected path is triggered?
Resources backing the VMA, including shmem pages_pin_count and the GEM object reference, can be released while the VMA remains alive. When the process later unmaps the range, normal VMA teardown calls close again, causing a reference-count underflow.
How does the fix change behavior when page insertion fails?
Instead of manually invoking the VMA close operation and returning a hard error, the fix uses a deferred-fault approach. This keeps the VMA alive and retries page insertion through the HMM range-fault path.