CVE-2026-89754: mm/pagewalk: fix stale walk->action escaping walk_pmd_range()
In the Linux kernel, the following vulnerability has been resolved:
mm/pagewalk: fix stale walk->action escaping walkpmdrange()
If ->pmdentry() sets walk->action = ACTIONAGAIN, the pmdnone() check is retried. The PMD entry may be cleared at the point of retry.
In this case, if walk->ops->installpte is not specified, the code continues to the next PMD entry in the range without resetting walk->action to ACTIONSUBTREE.
This leaves walk->action erroneously set to ACTIONAGAIN, which is incorrect.
This was incorrect but not problematic up until commit 3b89863c3fa4 ("mm/pagewalk: fix race between concurrent split and refault") which updated walkpudrange() to check for walk->action == ACTIONAGAIN upon walkpmdrange()'s return, causing the PUD walk to be retried.
In this case this results in duplicate walk callbacks being invoked, which is erroneous and will break any caller that is not idempotent with respect to this (and waste time for those which are). The result is an out-of-bounds write, triggered by a local fuzzer:
[ 2.272695] ================================================================== [ 2.273471] BUG: KASAN: slab-out-of-bounds in mincoreunmappedrange+0x14f/0x190 [ 2.274302] Write of size 1 at addr ffff888008d9b000 by task poc/106 [ 2.274966] [ 2.275154] CPU: 0 UID: 1000 PID: 106 Comm: poc Not tainted 7.2.0-rc6-00429-ga7c7074b58d2 #55 PREEMPT(lazy) [ 2.275159] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 2.275164] Call Trace: [ 2.275170] <TASK> [ 2.275172] dumpstacklvl+0x53/0x70 [ 2.275200] printreport+0xd0/0x630 [ 2.275210] ? pfxrawspinlockirqsave+0x10/0x10 [ 2.275219] ? irqentryexit+0xd2/0x670 [ 2.275224] ? irqentryexit+0xd2/0x670 [ 2.275226] ? virtaddrvalid+0xef/0x1a0 [ 2.275239] ? mincoreunmappedrange+0x14f/0x190 [ 2.275242] kasanreport+0xce/0x100 [ 2.275245] ? mincoreunmappedrange+0x14f/0x190 [ 2.275248] mincoreunmappedrange+0x14f/0x190 [ 2.275252] mincoreunmappedrange+0x45/0x70 [ 2.275254] walkpgdrange+0xafc/0xfc0 [ 2.275261] ? pfxwalkpgdrange+0x10/0x10 [ 2.275264] ? updateloadavgse+0x3d1/0x670 [ 2.275275] walkpagerange+0xc0/0x310 [ 2.275278] ? pfxfindvma+0x10/0x10 [ 2.275281] ? finishtaskswitch.isra.0+0x16d/0x4f0 [ 2.275290] walkpagerangemmunsafe+0x26f/0x3a0 [ 2.275293] ? pfxmtreeload+0x10/0x10 [ 2.275298] ? pfxwalkpagerangemmunsafe+0x10/0x10 [ 2.275302] ? freefrozenpages+0x54d/0x7e0 [ 2.275308] dosysmincore+0x132/0x380 [ 2.275311] dosyscall64+0xf9/0x540 [ 2.275316] entrySYSCALL64afterhwframe+0x77/0x7f [ 2.275322] RIP: 0033:0x422ccd [ 2.275326] Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 [ 2.275329] RSP: 002b:00007fffffffec18 EFLAGS: 00000287 ORIGRAX: 000000000000001b [ 2.275337] RAX: ffffffffffffffda RBX: 0000000000000066 RCX: 0000000000422ccd [ 2.275339] RDX: 00000000004d0940 RSI: 0000000001000000 RDI: 00007ffff4000000 [ 2.275340] RBP: 00000000004d0940 R08: 0000000000000100 R09: 0000000000000100 [ 2.275342] R10: 0000000000000100 R11: 0000000000000287 R12: 20c49ba5e353f7cf [ 2.275343] R13: 00000000004990d3 R14: 0000000000000000 R15: 0000000000000001 [ 2.275346] </TASK> [ 2.275347] [ 2.296904] The buggy address belongs to the object at ffff888008d9b000 [ 2.296904] which belongs to the cache sigqueue of size 80 [ 2.298151] The buggy address is located 0 bytes inside of [ 2.298151] allocated 80-byte region [ffff888008d9b000, ffff888008d9b050) [ 2.299408] [ 2.299601] The buggy address belongs to the physical page: [ 2.300191] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8d9b ---truncated---
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (mm/pagewalk: fix stale walk->action escaping walk_pmd_range())to a version that resolves this vulnerability.Patch commit 3b89863c3fa4
Event History
Frequently Asked Questions
What conditions are required for the erroneous retry to occur?
A page-walk pmd_entry callback must set walk->action to ACTION_AGAIN, the PMD must be cleared when the pmd_none() check is retried, and the walk operations must not specify install_pte. Under those conditions, the stale ACTION_AGAIN value can escape the PMD range walk.
What is the practical impact on page-walk callers?
The PUD walk can be retried after walk_pmd_range() returns, causing duplicate walk callbacks. Callers that are not idempotent with respect to duplicate callbacks can break; idempotent callers may still incur wasted work.
How was the memory-safety impact observed?
The issue was triggered by a local fuzzer and produced a KASAN slab-out-of-bounds report in __mincore_unmapped_range. The provided information does not describe a remote trigger.