CVE-2026-98918

UNRATEDCVSS · not yet scored

Also known asEUVD-2026-108882 (ENISA EUVD) · GHSA-2q7x-49g7-vwpm (GitHub Security Advisories)Source: ENISA EUVD

—
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • No CVSS published and no exploitation signals yet
CISA-KEV: Not listedEPSS PROB: 0.2%CVSS v2: —Exploit: None knownExposed services: Not assessed

A fixed version is listed under Patch Availability — apply it.

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

mm/damon/ops-common: use a page-aligned address in damon_ptep_mkold()

__damon_va_prepare_access_check() picks a random byte address within the region and stores it in r->sampling_addr. damon_va_mkold() passes it into a page table walk, which hands it to damon_ptep_mkold() as the address of the page to sample:

damon_va_mkold(mm, r->sampling_addr) damon_va_walk_page_range(mm, addr, addr + 1) damon_mkold_pmd_entry() damon_ptep_mkold(pte, vma, addr) ptep_test_and_clear_young(vma, addr, pte) mmu_notifier_clear_young(mm, addr, addr + PAGE_SIZE)

For arm64, before commit 6f0e1142173a ("arm64: mm: support batch clearing of the young flag for large folios"), the contpte helper walked exactly CONT_PTES entries from the aligned-down page table pointer and used @addr only to pass down to each entry, so an unaligned value was harmless:

ptep = contpte_align_down(ptep); addr = ALIGN_DOWN(addr, CONT_PTE_SIZE); for (i = 0; i < CONT_PTES; i++, ptep++, addr += PAGE_SIZE)

Now the range to walk is derived from @addr instead: end = addr + nr * PAGE_SIZE, rounded up to CONT_PTE_SIZE. For a sample in the last page of a contpte block, the sub-page offset puts end just past the block boundary, so the round-up lands a whole block further and the walk clears PTE_AF in CONT_PTES entries beyond the sampled block. For the last block in a page table page, those entries are past the end of that page, so the walk writes into the page that follows.

Triggered by the full 7.1/7.2 kernel selftest suite on arm64 (EC2 c/m6g.4xlarge). The kernel sometimes crashes at or shortly after the DAMON test.

What the overrun does depends on the page that happens to follow the page table, so there is no single signature. If that page is read-only, the write faults in the sampling path itself:

Unable to handle kernel write to read-only memory at virtual address ffff0003c5d2d000 FSC = 0x0f: level 3 permission fault CM = 0, WnR = 1, TnD = 0, TagAccess = 0 CPU: 10 UID: 0 PID: 3487 Comm: kdamond.2 pc : contpte_test_and_clear_young_ptes+0x70/0xc0 lr : damon_ptep_mkold+0x1e8/0x1f8 Call trace: contpte_test_and_clear_young_ptes+0x70/0xc0 (P) damon_mkold_pmd_entry+0x150/0x170 walk_pmd_range+0x110/0x2b0 walk_pud_range+0x10c/0x208 walk_pgd_range+0x134/0x258 __walk_page_range+0x98/0x1b0 walk_page_range_vma_unsafe+0x90/0x148 walk_page_range_vma+0x28/0x40 damon_va_walk_page_range+0x114/0x2b8 damon_va_prepare_access_checks+0xec/0x1a8 kdamond_fn+0x534/0x770 kthread+0x128/0x138 ret_from_fork+0x10/0x20

Otherwise the page is writable, the PTE_AF clearing succeeds silently and the damage only surfaces later, in whatever happened to own the page, so the backtrace is unrelated to DAMON and differs between runs.

Pass a page-aligned address to the ptep_test_and_clear_young() call in damon_ptep_mkold(), which is the only place DAMON can reach contpte_test_and_clear_young_ptes() from. Nothing else sees the aligned address, and r->sampling_addr itself is left as is, so the sampling and region bookkeeping semantics are unchanged.

CVSS v3
—
EchelonGraph score
Not yet assessedNo source has published severity data for this CVE yet — no CVSS score from NVD or a CNA, no GitHub advisory, and it is not in CISA KEV. This is not a rating of zero; we cannot assess it yet.
EG Score
—
EG Risk
—
EPSS PROB
0.2%
EPSS %ILE
5th
KEV
Not listed

What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)

EG Severity
Not assessed: no CVSS publishedA missing CVSS is not a severity of zero.
EG Likelihood
0.2% within 30 daysSource: FIRST EPSS. FIRST's exploitation probability, not an EchelonGraph model.
Confirmed exploitation
None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
EG Priority
No SSVC decision: EchelonGraph has not assessed this CVECISA BOD 26-04: 14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.Each input and its source, and whom BOD 26-04 binds: the BOD 26-04 block below.

BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.

The score's inputs: In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it

Published

October 23, 2026

Last Modified

October 23, 2026

Vendor Advisories for CVE-2026-98918(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Patch Availability(1)

Vendor / EcosystemFix (by version range) / PatchReleasedSource
linuxKernel @ 7.2.9 (fixes >=7.0.0)—osv

Patches are aggregated from vendor advisories (Red Hat, Microsoft, Cisco, GitHub) and package ecosystems (OSV, GHSA). Multiple rows for the same upstream release have been deduplicated.

Data Freshness Timeline

(refreshed 8× in last 7d / 16× in last 30d)

Each row is a time one of our pipelines fetched, updated or re-scored this CVE. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. An arrow marks a change the record states ("CVSS v3 → 9.1"); EPSS and GHSA rows show the values recorded at that time, not what changed (EPSS values are rounded; hover one for the exact figures). Most recent first.

  1. 2026-11-03 16:49 UTCEPSS rescoreEPSS 0.2% · 5th percentile
  2. 2026-11-02 16:46 UTCEPSS rescoreEPSS 0.2% · 5th percentile
  3. 2026-11-01 16:36 UTCEPSS rescoreEPSS 0.2% · 5th percentile
  4. 2026-10-31 18:25 UTCOSV refresh
  5. 2026-10-31 16:33 UTCEPSS rescoreEPSS 0.2% · 5th percentile
  6. 2026-10-30 16:35 UTCEPSS rescoreEPSS 0.2% · 5th percentile
  7. 2026-10-29 16:34 UTCEPSS rescoreEPSS 0.2% · 5th percentile
  8. 2026-10-28 16:33 UTCEPSS rescoreEPSS 0.2% · 5th percentile
  9. 2026-10-27 16:33 UTCEPSS rescoreEPSS 0.2% · 5th percentile
  10. 2026-10-26 16:33 UTCEPSS rescoreEPSS 0.2% · 5th percentile
  11. 2026-10-25 16:34 UTCEPSS rescoreEPSS 0.2% · 5th percentile
  12. 2026-10-25 13:46 UTCEG score recompute
  13. 2026-10-24 16:34 UTCEPSS rescoreEPSS 0.2% · 9th percentile
  14. 2026-10-23 13:25 UTCNVD update
  15. 2026-10-23 12:25 UTCEG score recompute
  16. 2026-10-23 12:24 UTCMITRE cvelistV5first tracked

Frequently asked(4)

What is CVE-2026-98918?
CVE-2026-98918 is a vulnerability whose severity is not yet rated; its CVE record was published on October 23, 2026. In the Linux kernel, the following vulnerability has been resolved: mm/damon/ops-common: use a page-aligned address in damon_ptep_mkold() __damon_va_prepare_access_check() picks a random byte address within the region and stores it in r->sampling_addr. damon_va_mkold() passes it into a page table…
When was the CVE record for CVE-2026-98918 published?
The CVE record for CVE-2026-98918 was published on October 23, 2026. That is the record's publication date; the vulnerability itself may have been made public earlier. EchelonGraph's copy of the record carries a last-modified date of October 23, 2026; the record at its source may have been updated since.
Is CVE-2026-98918 actively exploited?
CVE-2026-98918 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0.2% probability of exploitation in the next 30 days (5th percentile of EPSS-scored CVEs).
How do I remediate CVE-2026-98918?
A fixed version for CVE-2026-98918 is listed under Patch Availability on this page: update to the version listed for your package. The vendor advisories EchelonGraph has for CVE-2026-98918 are linked in the Vendor Advisories panel on this page.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-98918

Explore →

Is Your Infrastructure Affected by CVE-2026-98918?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.