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

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

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

damonvaprepareaccesscheck() picks a random byte address within the region and stores it in r->samplingaddr. damonvamkold() passes it into a page table walk, which hands it to damonptepmkold() as the address of the page to sample:

damonvamkold(mm, r->samplingaddr) damonvawalkpagerange(mm, addr, addr + 1) damonmkoldpmdentry() damonptepmkold(pte, vma, addr) pteptestandclearyoung(vma, addr, pte) mmunotifierclearyoung(mm, addr, addr + PAGESIZE)

For arm64, before commit 6f0e1142173a ("arm64: mm: support batch clearing of the young flag for large folios"), the contpte helper walked exactly CONTPTES 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 = contptealigndown(ptep); addr = ALIGNDOWN(addr, CONTPTESIZE); for (i = 0; i < CONTPTES; i++, ptep++, addr += PAGESIZE)

Now the range to walk is derived from @addr instead: end = addr + nr PAGESIZE, rounded up to CONTPTESIZE. 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 PTEAF in CONTPTES 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 : contptetestandclearyoungptes+0x70/0xc0 lr : damonptepmkold+0x1e8/0x1f8 Call trace: contptetestandclearyoungptes+0x70/0xc0 (P) damonmkoldpmdentry+0x150/0x170 walkpmdrange+0x110/0x2b0 walkpudrange+0x10c/0x208 walkpgdrange+0x134/0x258 walkpagerange+0x98/0x1b0 walkpagerangevmaunsafe+0x90/0x148 walkpagerangevma+0x28/0x40 damonvawalkpagerange+0x114/0x2b8 damonvaprepareaccesschecks+0xec/0x1a8 kdamondfn+0x534/0x770 kthread+0x128/0x138 retfromfork+0x10/0x20

Otherwise the page is writable, the PTEAF 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 pteptestandclearyoung() call in damonptepmkold(), which is the only place DAMON can reach contptetestandclearyoungptes() from. Nothing else sees the aligned address, and r->samplingaddr itself is left as is, so the sampling and region bookkeeping semantics are unchanged.