[CVE-2026-98918][MODERATE 7.0] mm/damon/ops-common: use a page-aligned address in damon_ptep_mkold()

[AL-KERNEL <alkernel@kernelcve.org>]

CVE: CVE-2026-98918
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: mm/damon/ops-common: use a page-aligned address in damon_ptep_mkold()
Commit: d5208de0799c506d3315b6f96d034c38e4509dbb
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d5208de0799c506d3315b6f96d034c38e4509dbb
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98918
Analysis date: Mon, 26 Oct 2026 21:29:06 -0400
ActionableScore: 4
ActionableScore lower bound: 3
Actionable bucket: Actionable Moderate / Strong Important candidate requiring manual review
Manual review required: YES

Summary:
An unaligned DAMON sample can make arm64 contpte clearing write beyond a page-table page into an adjacent kernel page, causing immediate faults or later corruption-dependent failures.

======================================================================
ABOUT THIS REPORT
======================================================================

The original Linux kernel CVE announcement for CVE-2026-98918 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98918

The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.

The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.

Published priority for this report: MODERATE 7.0
Manual review required: YES

A detailed explanation of the methodology and priority rules is included
at the end of this message.

======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================

CVE-2026-98918	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-98918 CHECK WITH IMPACT FROM ORIG NN MODERATE | AEGIS IMPACT MODERATE_KPANIC AEGIS_AS=3 LEGACY=MODERATE_KPANIC RESULT=SAME (final reconciliation agrees; DECISION: both MODERATE_KPANIC)	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H';*CWE-787;CWE-129;*CWE-20;Other CVSS 'AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '7';DESCR 'An unaligned DAMON sampling address can make the arm64 contpte young flag helper extend its walk beyond the sampled contpte block. At the end of a page table page this produces a confirmed out of bounds kernel write into the following page. The write is constrained to clearing PTE_AF like bits and is not an arbitrary write primitive. It can cause an immediate kernel fault when the adjacent page is read only or silent corruption with a later unrelated failure when that page is writable. For the CVSS the PR:L paranoid value applies when DAMON is already active and a local user can influence mappings or workload in a monitored target. AC:H reflects the random sampling position and memory layout conditions. The confirmed memory corruption supports manual review even though privilege escalation is not proven. Automated impact decision path. The original SimpleNet classifier selected MODERATE_KPANIC. The primary LLM estimated paranoid CVSS 7 and the production ActionableScore returned 4 with recommendation Actionable Moderate / Strong Important candidate requiring manual review. The production rules then evaluated CVSS thresholds and ActionableScore thresholds. No severity changing production threshold or specialist override was recorded. The legacy KP specialist produced a review artifact and its decision was processed by the applicable KP rules. The legacy FD or DH downgrade specialist has no review artifact for this run. The independent weaker Aegis shadow evaluated CVSS 3.7 and ActionableScore 3 with primitive class CLASS_B and manual review REQUIRED. Its independently reconciled impact was MODERATE_KPANIC. The shadow agreed with the final production impact and aggregation did not change that impact. The final reported impact is MODERATE_KPANIC.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 4)	MAYBE	OOB INIT HARDWARE LINUS KPANIC MEMORY 	-	-	checked

======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================

ActionableScore=4
ActionableScoreLower=3
PrimitiveClass=CLASS_B
RealUAF=NO
HostAdminRequired=UNKNOWN
NamespaceScopedPrivilege=UNKNOWN
ImportantCandidate=YES
ManualReview=REQUIRED
AutoDowngradeAllowed=NO
RequiresHostUID0=UNKNOWN
AuthorizationDecisionBypass=NO
ProtectedResourceImpact=NONE
B4PendingReview=NO
B4PendingConfirmed=NO

1. ActionableScore

* Raw base score: 3.
* Conservative score: 3; no floor or cap applied.
* Raw paranoid score: 4.
* Paranoid score: 4; no floor or cap applied.
* Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**::

2. Signal breakdown

* +2 confirmed kernel OOB write: an unaligned address extends the arm64 contpte walk beyond the page-table page and clears bits in the following kernel page.
* +1 reliable kernel crash/strong DoS: read-only adjacent pages fault immediately; writable pages can produce delayed failures.
* +1 active corrupted-state consumption: the commit confirms silent modification of a writable adjacent page whose owner may later consume the corrupted state. The exact object and operation remain unidentified.
* Base −1 hard/probabilistic trigger conditions: sampling must select the vulnerable end position and allocator placement determines whether the adjacent page yields useful corruption.
* Paranoid 0 timing penalty: ongoing DAMON sampling permits repeated opportunities, so the probabilistic condition may not be materially one-shot.
* No separate integrity, confidentiality, arbitrary-write, controlled-target, reclaim, or LPE points. Payload is constrained to the helper’s AF-bit-clearing operation.
* B5-R does not apply: no retry-accumulated index or missing retry reset is shown. B4-PENDING is unrelated because there is no authorization decision.

3. Reachability analysis

DAMON must be enabled and monitoring a suitable arm64 address space. A monitored process can influence its mappings and workload, but the evidence does not establish that an ordinary user can configure DAMON or complete the full trigger without prior privileged setup. Therefore host-admin and namespace privilege requirements remain unknown; no local-unprivileged bonus or privilege penalty is applied. No special physical hardware is required beyond affected arm64 contpte behavior.

4. Primitive and severity reading

The primitive is a real, bounded-pattern OOB write from a page-table page into the physically following kernel page. It is not a UAF and not an arbitrary or directed write. Immediate crash and silent corruption followed by later owner use are shown; useful victim selection and security-boundary impact are not. This is CLASS_B because material post-write leverage requires investigation. ImportantCandidate is YES and auto-downgrade is disallowed due confirmed cross-object kernel corruption with downstream consumption but unresolved target and privilege boundaries.

5. One-sentence report phrase

An unaligned DAMON sample can make arm64 contpte clearing write beyond a page-table page into an adjacent kernel page, causing immediate faults or later corruption-dependent failures.

6. Manual review advice

MANUAL CHECK REQUIRED

Confirm DAMON privilege/setup requirements, attacker influence over monitored mappings, adjacent-page allocation behavior, and concrete downstream consumers.

7. Call-site confidence

Call-site confidence: high

======================================================================
UPSTREAM PATCH SUMMARY
======================================================================

Patch: mm/damon/ops-common: use a page-aligned address in damon_ptep_mkold()
Commit: d5208de0799c506d3315b6f96d034c38e4509dbb
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d5208de0799c506d3315b6f96d034c38e4509dbb

Commit description:

__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 6f0e114 ("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.

Link: https://lore.kernel.org/20260904002829.116381-1-sj@kernel.org
Fixes: 6f0e114 ("arm64: mm: support batch clearing of the young flag for large folios")
Signed-off-by: Nathan Gao <zcgao@amazon.com>
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: SJ Park <sj@kernel.org>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: David Hildenbrand (Arm) <david@kernel.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Changed files:
  mm/damon/ops-common.c

Diff excerpt:

Not included in this email. See the upstream URL for the full patch.

Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d5208de0799c506d3315b6f96d034c38e4509dbb

======================================================================
DETAILED REPORT METHODOLOGY
======================================================================

The original Linux kernel CVE announcement for CVE-2026-98918 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98918

The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.

The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.

The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.

Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:

  Conservative CVSS vector: AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H
  The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
  The Best / paranoid CVSS score: 7

The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.

CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.

A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.

  Conservative ActionableScore: 3
  Paranoid ActionableScore: 4

The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.

For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:

  ActionableScore below 5   -> MODERATE REGULAR
  ActionableScore 5 or more -> MODERATE 7.0

The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.

There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).

KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.

AL-KERNEL base severity for this report: MODERATE
KPANIC detected for this report: YES
Published priority for this report (same as in Subject): MODERATE 7.0

These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).

Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is alexanjelausa@gmail.com (and both
send reply to CVE record itself too and see "reply" button below for howto reply).