EUVD-2026-103747
GHSA-jr3f-x4p8-9x32
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessExecute local unprivileged process
-
DeliveryCreate adjacent anon_vma-compatible VMAs via mprotect
-
ExploitFault both VMAs concurrently from two threads
-
ExecutionWin store-reordering window in __anon_vma_prepare
-
ImpactTrigger anon_vma->root use-after-free and lock hang
Vulnerability Assessment
| Exploitation Conditions | Requires the ability to run local unprivileged code on the target. The specific trigger stated in the source: two adjacent VMAs that are anon_vma-compatible but not merged (e.g. differing in VMA_ACCESS_FLAGS changeable via mprotect), with two threads concurrently faulting on each VMA while holding mmap_lock only for reading, so that __anon_vma_prepare() reuses/publishes an anon_vma while another thread finds it via find_mergeable_anon_vma(). Exploitation is further gated by winning a store-reordering race between the anon_vma->root store and the vma->anon_vma store; this was observed on arm64 and is realistically reachable only on weak-memory-ordering architectures (strongly-ordered x86 is far less likely to reorder these stores). Limiting factors: local access only, a tight concurrency/timing window, a non-default memory layout the attacker must arrange, and architecture dependence - all of which sharply reduce real-world exploitability despite the 7.8 base score. |
| Impact | Signals point to a genuine but low-urgency local kernel bug rather than a high-priority exploitation target. The supplied CVSS vector (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, 7.8) describes a locally-reachable flaw requiring only low privileges, but the description makes clear the trigger is a store-reordering race in __anon_vma_prepare() that requires two threads concurrently faulting on two adjacent, anon_vma-compatible-but-unmerged VMAs - a tight timing window observed only as a hung-task symptom on an arm64 (weak-memory-ordering) server. This is why I assess attack complexity as high (AC:H) rather than the input's AC:L: the evidence explicitly describes a reordering race, not a deterministic single-request trigger. EPSS is low (0.20%, 9th percentile), there is no CISA KEV listing, and no public exploit is identified - all consistent with a hard-to-win local race rather than a weaponizable primitive. The confirmed observed impact is denial of service (anon_vma->root use-after-free causing an un-releasable lock and permanently blocked tasks); escalation of the UAF to confidentiality/integrity compromise is theoretically implied by the C:H/I:H/A:H rating but is not demonstrated in the available sources. The vuln.today 'this_week' decision label aligns with normal stable-kernel patch cadence, not emergency action. Note the input Tag 'Information Disclosure' is inconsistent with the described use-after-free/DoS mechanism - treat the categorization with caution. |
| Exploit ScenarioDerived | A local unprivileged user runs a process that creates two adjacent anon_vma-compatible VMAs that are not merged (e.g. by changing access flags with mprotect) and spawns two threads that page-fault on each VMA simultaneously while holding mmap_lock for reading. On a weak-memory-ordering CPU (arm64 observed), the store to anon_vma->root and the store to vma->anon_vma are reordered, so the second thread locks a stale root, producing a use-after-free of anon_vma->root that leaves locks permanently held and tasks hung. No public exploit code is identified at time of analysis; the only references are the fix commits. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
A missing memory barrier in the Linux kernel's mm/rmap anon_vma preparation path allows a use-after-free of anon_vma->root, which in turn leaves one anon_vma rwsem permanently locked and makes another unacquirable, producing hung-task stalls and memory-management corruption. Only local users are affected (PR:L in the assessed vector), and the bug is reachable only when two threads concurrently fault on two adjacent, anon_vma-compatible but unmerged VMAs while holding mmap_lock for read, and only if the anon_vma->root store is reordered after the vma->anon_vma store - a window observed on arm64 and realistically attainable only on weakly-ordered architectures. No public exploit code was identified at time of analysis, EPSS is low (0.20%, 9th percentile), the issue is not in CISA KEV, and vendor patches are available, so priority is moderately low despite the 7.8 base score.
RemediationAI
Apply the vendor-released kernel updates containing the barrier fix: upgrade to Linux 6.12.112, 6.18.55 or 7.2.9 (or 7.3-rc5 and later on the mainline track), which correspond to upstream commit 465e222815c8839445d09028fa4c77e70f7f1c7d, and confirm the stable backports a500df43cde075f6ea4b8bae495d89f2c35b3e16, 4cef512a955e4008ae4436a4fc97726976df1fdf, d348a715380bfcc6a611bdf722169d53fd01e735 and b6ac0b3f6013c168f22cad97e79967accacb08e1 are present in your distribution kernel before treating hosts as fixed (advisory links: https://nvd.nist.gov/vuln/detail/CVE-2026-98507 and the git.kernel.org stable commits above). Because the race is in core anonymous-memory bookkeeping and is exercised through ordinary page faults, there is no targeted configuration switch, port or endpoint that can be disabled to remove exposure; the realistic compensating controls are reducing the chance of the concurrent adjacent-VMA fault pattern (for example, avoiding workloads that mprotect and fault neighbouring anonymous mappings from many threads at once on arm64 hosts) and monitoring for hung tasks blocked in rwsem_down_write_slowpath/__anon_vma_prepare as an indicator of the lock imbalance - both reduce likelihood or detect impact but leave the underlying race in place until the kernel is updated. Prioritisation can follow the vendor patch cadence rather than emergency handling, given no public exploit code, low EPSS and absence from KEV.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw lives in the reverse-mapping (rmap) machinery that builds anon_vma chains for anonymous memory so that page-table entries can be found during reclaim and migration. anon_vma objects are allocated from an SLAB_TYPESAFE_BY_RCU cache, so freed memory can be handed to a new anon_vma immediately, and the constructor anon_vma_ctor() plus __put_anon_vma() never reset anon_vma->root, meaning a stale root pointer survives reuse until anon_vma_alloc() overwrites it. __anon_vma_prepare() runs with mmap_lock held only for reading, so two threads can fault on adjacent VMAs simultaneously: thread A allocates an anon_vma, sets anon_vma->root = anon_vma, then publishes vma->anon_vma with a plain store, while thread B discovers that anon_vma through find_mergeable_anon_vma() and calls anon_vma_lock_write(). Because the acquire semantics of anon_vma_lock_write()/spin_lock() do not order prior stores and the matching release operations happen too late, A's two stores can be observed by B in reverse order - vma->anon_vma first, anon_vma->root second - so B takes a write lock on the stale root while the unlock path releases the new root. The result is a permanently held rwsem (root->rwsem.count of -1) and a second anon_vma that can no longer be locked, matching the reported arm64 hung-task trace through __anon_vma_prepare()/do_anonymous_page(). Because the reordering requires weak store ordering, x86 and other strongly-ordered targets are far less likely to exhibit it, and the trigger demands a deliberately arranged VM layout plus a tight concurrency window.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Local trigger (AV:L) by an unprivileged process (PR:L, UI:N); AC:H because the source describes a store-reordering race requiring concurrent faults on a specific VMA layout; UAF can corrupt kernel memory, so C/I/A:H.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
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---
Executive ViewAI
A high-severity Linux kernel memory management flaw (CVE-2026-98507) can cause system stalls and corruption when triggered by concurrent local operations on weakly-ordered architectures like arm64. While no public exploit code exists and the attack requires specific race conditions, affected systems could suffer availability disruptions. Leadership should prioritize patching this kernel vulnerability to maintain system reliability and security, especially in cloud and edge deployments using arm64.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB