CVE-2026-74599

mm/ptdump: always stabilise against page table freeing using init_mm

N/A
Published: August 22, 2026 at 03:31 PM UTC
Updated: October 30, 2026 at 01:20 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: mm/ptdump: always stabilise against page table freeing using init_mm Previous commits have established the invariant that kernel page table freeing is performed while an mmap read lock on init_mm is held, which fixes races between ptdump and kernel page table freeing over init_mm. However, x86 and arm64 can perform a ptdump over an mm other than init_mm via ptdump_walk_pgd() and since kernel memory ranges are shared across non-kernel mm's, this means that the race still exists for these cases. Fix this by acquiring a nested mmap write lock for init_mm in ptdump_walk_pgd(). This is safe as we take this after mmap write locking the mm, and nothing acquires the init_mm lock first before locking an arbitrary mm, so no deadlock is possible. Also update walk_page_range_debug() to assert that init_mm is write locked, add a comment explaining why and remove some redundant code, and eliminate the unnecessary and confusing invocation of walk_kernel_page_table_range(). We can safely remove the non-NULL check for walk.mm, as the mmap lock asserts would NULL pointer deref if it was (and of course no callers do this). The first point at which ptdump can race kernel page table freeing is commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table"), so we target this in the Fixes tag.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

4.14.31 ≤ v < 4.154.15.14 ≤ v < 4.164.4.125 ≤ v < 4.54.9.91 ≤ v < 4.100454e2fad9306961540ee7e84da47a8e345b7d2231895cfd79564111cdd5a9f48c5d491ae26a238e4.14.314.15.144.164.4.1254.9.91454e2fad9306961540ee7e84da47a8e345b7d229c7f7bdb1932f8c1e5f80d32c717184701afe701acdb4981644c8e31ccee294bdefff475c0cf587bb6bdb7517c3d3f41f20e5c2948d6bc3f8897394e
Vendor states this is fixed in 27c32e5538344b13c1505a08861e04620c125d47 (fixed)
Vendor states this is fixed in 3c0391b9a774cc0854f3152e484a9d4835b12b40 (fixed)
Vendor states this is fixed in 4adc4c9a9a43d61fe476dfe10811f3df2e7e4106 (fixed)
Vendor states this is fixed in 76df4edf7d61ecb711bc517ff4c20a5e85c4e9f7 (fixed)
Vendor states this is fixed in 7f740664aec1f832953c2e6d9b8920cd6c8bcc0c (fixed)
Vendor states this is fixed in b9c6d048bdfaae78d7d921b454f7de7baefaa2f0 (fixed)
Vendor states this is fixed in cbd9583bb6f70733d0022a66d3546a15c76ae744 (fixed)
Affected range stops below 4.10, so it looks safe — our inference, not a vendor statement
Affected range stops below 4.15, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 4.16 (unaffected)
Affected range stops below 4.5, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 5.10.266 (unaffected)
Vendor states this is fixed in 5.15.217 (unaffected)
Vendor states this is fixed in 6.12.105 (unaffected)
Vendor states this is fixed in 6.18.45 (unaffected)
Vendor states this is fixed in 6.6.153 (unaffected)
Vendor states this is fixed in 7.1.9 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card