CVE-2026-74599

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