CVE-2026-90303: ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults
In the Linux kernel, the following vulnerability has been resolved:
ARM: 9485/1: mm: acquire mmap write lock around showpte() for user faults
When CONFIGDEBUGUSER=y, and cmdline "userdebug=31" is set, a user fault may trigger showpte() without any lock. If another thread in the same process concurrently calls munmap(), the page table pages may be freed while showpte() is still traversing them, causing a use-after-free in showpte().
If CONFIGARMLPAE=y, this may cause a kernel panic if the pages table of PMD are freed when showpte() is running.
Acquire mmapwritelock() around showpte() for user faults to fix the contention.
For user faults, additionally restrict that showpte() is called only when the addr is a user-space address (addr < TASKSIZE). This is because the lock of tsk->mm only protects the virtual memory of user address space, furthermore, dumping the page tables of a kernel-space address for user faults is unnecessary and may have security implications.
Keep everything unchanged for kernel faults, because the kernel is already in the "oops" state, acquiring a lock may risk a deadlock.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The affected path requires an ARM Linux kernel built with CONFIG_DEBUG_USER=y and booted with the user_debug=31 command-line setting. The reported panic scenario additionally applies when CONFIG_ARM_LPAE=y.
What conditions are needed to trigger the use-after-free?
A user fault must cause show_pte() to traverse page tables while another thread in the same process concurrently calls munmap(). The concurrent unmap can free page-table pages that show_pte() is still accessing.
Are default kernel configurations affected?
The vulnerable behavior depends on the debug-specific CONFIG_DEBUG_USER configuration and the explicit user_debug=31 boot parameter. The supplied information does not indicate that these are enabled by default.
What is the practical impact on ARM systems using LPAE?
If CONFIG_ARM_LPAE=y, freeing PMD page-table pages during show_pte() traversal may cause a kernel panic.
What mitigation is available if the fix cannot be deployed immediately?
Avoid enabling CONFIG_DEBUG_USER with the user_debug=31 command-line setting on affected ARM systems. This prevents the described user-fault show_pte() path from being triggered.