Cloudanix VulnDB

CVE-2026-98505

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A small timing flaw in the Linux kernel's memory monitoring code could let hardware updates get lost, but the problem is unlikely to affect normal operations and has no known attacks.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Other
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in damon_hugetlb_mkold() where concurrent hardware PTE updates can be lost when the function reads, modifies, and writes the entry without atomicity, potentially dropping dirty or accessed bits.

Why it matters to the business

Low operational risk for systems using hugetlbfs with DAMON enabled; recent disclosure with negligible exploitation probability means minimal immediate disruption to workloads or compliance posture.

How an attack unfolds

An attacker would need local code execution and precise timing to trigger parallel hardware PTE writes during the vulnerable window in damon_hugetlb_mkold(), but the in-memory nature of hugetlbfs and page-fault serialization limit any practical impact or data corruption.

How to fix it

Upgrade to a Linux kernel containing the fix that replaces the read-modify-write sequence with huge_ptep_get_and_clear(); apply the patch from the mainline commit resolving the issue as soon as a distribution backport becomes available.

How to confirm the fix worked

Confirm the kernel source contains the huge_ptep_get_and_clear() call inside damon_hugetlb_mkold(); recompile, boot the new kernel, and exercise DAMON on hugetlb regions while monitoring for page-fault handling under the page-table lock.

Typical attack path

  1. Obtain local execution on a Linux system with DAMON hugetlb monitoring active
  2. Map hugetlb pages and induce concurrent memory writes while damon_hugetlb_mkold() executes
  3. Rely on hardware to update PTE bits in the narrow race window
  4. Observe loss of dirty-bit information in subsequent page-table walks

How to detect it

Examine kernel logs and audit trails for unexpected page-fault patterns or DAMON-related warnings around hugetlb mappings; review source-level changes rather than runtime artifacts since no public exploit code exists.

What your security team should do

  • Prioritize kernel updates on systems that actively use DAMON with hugetlb pages
  • Monitor upstream stable and distribution kernels for the backported fix
  • Review DAMON configuration to determine exposure scope before applying changes

The record

In the Linux kernel, the following vulnerability has been resolved: mm/damon/vaddr: avoid hw-driven pte updates during damon_hugetlb_mkold() damon_hugetlb_mkold() reads the page table entry into a local variable, unsets the accessed bit in the variable, and updates the page table entry with the updated variable value. If hardware updates the same page table entry in parallel, the hw updates could be lost. For example, hardware-updated dirty bits might be lost. Avoid the parallel updates by clearing the page table entry when reading it together, using huge_ptep_get_and_clear(). If a parallel write to the memory is made after the clearing, the hw will see the page table entry is cleared, trigger page fault and wait until it is handled. The page fault handling will wait for damon_hugetlb_mkold() due to the page table lock. Because hugetlbfs is an in-memory file system and hugetlb pages cannot be reclaimed, no critical issue is expected to my best knowledge. But definitely this is a nasty bug that should be fixed sooner rather than later. The issue was discovered [1] by Sashiko.

Affected packages

Ecosystem Package Introduced Fixed