CVE-2026-98507 - Vulnerability Details

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

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---

Published: 2026-10-18

Score: n/a

EPSS: n/a

KEV: No

Impact:

Action:

Analysis

Impact

An internal race condition in the Linux kernel’s anonymous VMA preparation code allows two concurrent page faults on adjacent anonymous memory areas to interleave in a way that disables the lock publication barrier. This missing synchronization permits a use‑after‑free of the anon_vma root structure and causes the kernel’s rwsem to be left in an inconsistent state. The result is a deadlock where one VMA never unlocks, preventing other VMA locks from being acquired and causing a task to hang indefinitely. The effect is a denial‑of‑service that can freeze user processes or the entire system.

Affected Systems

Linux kernel versions prior to the commit that added the missing barrier are vulnerable. The defect was observed on an arm64 server running the 5.10.0‑0021.aarch64 kernel. Because the bug resides in the core memory management subsystem, it applies to all architectures and kernels that include the old mm/rmap code without the applied patch.

Risk and Exploitability

There is no public exploit for this issue, and the EPSS score is not available. The vulnerability requires two threads to fault concurrently on adjacent anonymous VMAs, which makes reliable triggering nontrivial but still feasible for a local attacker. The very high impact of a kernel‑level deadlock means the risk is moderate to high. The issue is not listed in the CISA KEV catalog, but it can cause a complete denial of service.

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions

Linux

unaffected

Version	Status	Constraints
`5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1`	affected	< a500df43cde075f6ea4b8bae495d89f2c35b3e16
`5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1`	affected	< 4cef512a955e4008ae4436a4fc97726976df1fdf
`5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1`	affected	< d348a715380bfcc6a611bdf722169d53fd01e735
`5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1`	affected	< b6ac0b3f6013c168f22cad97e79967accacb08e1

Linux

affected

Version	Status	Constraints
`2.6.36`	affected	—
`0`	unaffected	< 2.6.36
`6.12.112`	unaffected	≤ 6.12.*
`6.18.55`	unaffected	≤ 6.18.*
`7.2.9`	unaffected	≤ 7.2.*
`7.3-rc5`	unaffected	≤ *

No data.

No data available yet.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

Upgrade the Linux kernel to a version that contains the commit fixing the anon_vma barrier.
If an official kernel update is not immediately available, apply the specific patching commits referenced in the advisory to your source tree and rebuild the kernel.
As a temporary measure, muting the hung task timeout message by echoing 0 to /proc/sys/kernel/hung_task_timeout_secs can reduce alert noise, though it does not address the underlying lock inconsistency.

Generated by OpenCVE AI on October 18, 2026 at 16:53 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

No CVSS v4.0

No CVSS v3.1

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

No EPSS score available.

Key SSVC decision points have not yet been added.

References

Link	Providers
https://git.kernel.org/stable/c/4cef512a955e4008ae4436a4fc97726976df1fdf
https://git.kernel.org/stable/c/a500df43cde075f6ea4b8bae495d89f2c35b3e16
https://git.kernel.org/stable/c/b6ac0b3f6013c168f22cad97e79967accacb08e1
https://git.kernel.org/stable/c/d348a715380bfcc6a611bdf722169d53fd01e735

History

Sun, 18 Oct 2026 17:15:00 +0000

Type	Values Removed	Values Added
Weaknesses		CWE-362 CWE-416

Sun, 18 Oct 2026 15:30:00 +0000

Type	Values Removed	Values Added
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---
Title		mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish
First Time appeared		Linux Linux linux Kernel
CPEs		cpe:2.3:o:linux:linux_kernel::::::::
Vendors & Products		Linux Linux linux Kernel
References		https://git.kernel.org/stable/c/4cef512a955e4008ae4436a4fc97726976df1fdf https://git.kernel.org/stable/c/a500df43cde075f6ea4b8bae495d89f2c35b3e16 https://git.kernel.org/stable/c/b6ac0b3f6013c168f22cad97e79967accacb08e1 https://git.kernel.org/stable/c/d348a715380bfcc6a611bdf722169d53fd01e735

Subscriptions

Linux Linux Kernel

MITRE

Status: PUBLISHED

Assigner: Linux

Published: 2026-10-18T15:17:13.767Z

Updated: 2026-10-18T15:17:13.767Z

Reserved: 2026-09-25T10:25:14.354Z

Link: CVE-2026-98507

Vulnrichment

No data.

NVD

Status : Received

Published: 2026-10-18T16:17:01.817

Modified: 2026-10-18T16:17:01.817

Link: CVE-2026-98507

Redhat

No data.

OpenCVE Enrichment

Updated: 2026-10-18T17:00:09Z

Weaknesses

CWE-362
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
CWE-416
Use After Free

Impact

Affected Systems

Risk and Exploitability

Tracking

Subscriptions

JSON object

JSON object

JSON object

JSON object

JSON object