CVE-2026-98507: mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish

In the Linux kernel, the following vulnerability has been resolved:

mm/rmap: fix missing barrier between anonvma init and vma->anonvma publish

On arm64 server, we find that a task trying to grab the anonvma lock triggers hungtask.

INFO: task main:2354726 blocked for more than 120 seconds. Tainted: G E 5.10.0-0021.aarch64 #1 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:main state:D stack: 0 pid:2354726 ppid:2350673 flags:0x00000a01 Call trace: switchto+0x7c/0xbc schedule+0x3b4/0x8a0 schedule+0x50/0xe0 rwsemdownwriteslowpath+0x3cc/0x6cc downwrite+0x60/0x260 anonvmaprepare+0x6c/0x210 doanonymouspage+0x258/0x660 handleptefault+0x188/0x214 handlemmfault+0x1b0/0x380 handlemmfault+0xf4/0x284 dopagefault+0x19c/0x494 dotranslationfault+0xcc/0xf8 domemabort+0x48/0xac el0da+0x44/0x80 el0synchandler+0x88/0xb4 el0sync+0x160/0x180

After analyzing the vmcore, we found the anonvma->root->rwsem.count is -1. There is another anonvma whose anonvma->root->rwsem.count is 1, the anonvma->root->rwsem.owner shows the lock is held, but the stack of the task shows the task doesn't hold the anonvma lock.

After adding more debugging info, we found anonvmaprepare() reuses anonvma and triggers the UAF of anonvma->root due to missing memory barrier, leading to locking and unlocking two different anonvma->root, thus leading to an anonvma will never be unlocked, and another anonvma couldn't be locked anymore.

This race requires two adjacent VMAs that are not merged but are anonvma-compatible (e.g., they differ in VMAACCESSFLAGS that can be changed by mprotect()). Two threads fault on each VMA concurrently, both calling anonvmaprepare() with only mmaplock held for reading.

THREAD A THREAD B anonvmaprepare anonvmaprepare findmergeableanonvma() -> NULL anonvma = anonvmaalloc(); anonvma->root = anonvma; // the two stores may be reordered vma->anonvma = anonvma; // finds A's anonvma anonvma = findmergeableanonvma(vma); anonvmalockwrite(anonvma); // may still see the old root downwrite(&anonvma->root->rwsem); anonvmaunlockwrite(anonvma); // see the new root, never unlock old upwrite(&anonvma->root->rwsem);

thread A triggers page fault and calls anonvmaprepare() to prepare anonvma for the faulting vma. anonvmaprepare() allocates and initializes a new anonvma, and then publishes it to the vma with a plain store. anonvmaprepare() only requires the mmaplock to be held for reading, so two threads can fault on adjacent VMAs at the same time. While thread A publishes a new anonvma, thread B could find the anonvma via findmergeableanonvma() and then locks anonvma->root->rwsem.

The store to anonvma->root in anonvmaalloc() and the store to vma->anonvma can be reordered. The anonvmalockwrite() and spinlock() only provide acquire semantics, which do not prevent prior stores from being reordered after them. The release semantics of the corresponding spinunlock() and anonvmaunlockwrite() come too late, the store to vma->anonvma is already published before they take effect. As a result, thread B can observe the following order:

vma->anonvma = anonvma; anonvma->root = anonvma;

The anonvma slab is SLABTYPESAFEBYRCU, so a newly allocated anonvma may reuse memory from a previously freed one. The constructor (anonvmactor) does not reset anonvma->root, and putanonvma() doesn't clear it either, so the old root value persists until anonvmaalloc() overwrites it. If that store isn't v ---truncated---