CVE-2026-74672

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF<br /> <br /> Patch series "mm: fix UAF caused by race between ptdump and vmap pgtable<br /> freeing", v6.<br /> <br /> Kernel page table walkers fall into two broad categories - those ranges<br /> where no exclusion is required via walk_kernel_page_table_range_lockless()<br /> and those where exclusion is required via walk_kernel_page_table_range()<br /> or walk_page_range_debug().<br /> <br /> The former category is used only by arm64 arch code operating on ranges it<br /> both wholly owns and does not concurrently write.<br /> <br /> The latter category consists of kernel page table walkers operating on<br /> ranges that are wholly owned (but which need exclusion against concurrent<br /> writers).<br /> <br /> The lock used for exclusion is the mmap lock, and for kernel ranges this<br /> is the mmap lock on init_mm.<br /> <br /> ptdump is a special case being both the only user of<br /> walk_page_range_debug(), and the only case in which it walks ranges it<br /> does not own.<br /> <br /> This presents a problem, as page tables may be freed under ptdump. And<br /> indeed there is a use-after-free bug in the kernel as a result, which this<br /> series addresses.<br /> <br /> vmap promotes page tables to huge leaf entries where possible, freeing the<br /> lower page table when it does. It does this with no meaningful locks held<br /> against concurrent ptdump walks.<br /> <br /> As a result, use-after-free can currently occur. This series addresses<br /> the issue by having the vmap huge promotion logic acquire the mmap read<br /> lock while both setting the huge page table entry and freeing the prior<br /> leaf page table.<br /> <br /> The ptdump code already acquires the mmap write lock, so by doing so we<br /> ensure that the ptdump walker only ever observes either the huge page<br /> table entry or the existing page table entry, and nothing is freed<br /> underneath it.<br /> <br /> A mitigation for this issue was already applied for arm64 in commit<br /> fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), which this series<br /> has to deal with carefully.<br /> <br /> This mitigation resolves the issue by acquiring the mmap read lock on<br /> init_mm on vmap page table free if a ptdump is in progress.<br /> <br /> However the fix in this series would cause a deadlock if we were to simply<br /> apply it for arm64 without also reverting the change.<br /> <br /> This is because vmap may acquire the read lock before ptdump attempts to<br /> acquire the write lock, which then gets queued, and rwsem starvation rules<br /> mean that the (unacknowledged) nested mmap read lock in the arm64 code<br /> would also block, meaning the original read lock is never released and<br /> thus deadlock.<br /> <br /> This series works around this by #ifndef CONFIG_ARM64&amp;#39;ing the mmap read<br /> lock in vmap logic, then partially reverting commit fa93b45fd397 ("arm64:<br /> Enable vmalloc-huge with ptdump"), keeping the enablement of huge vmap<br /> support, and removing the ifdeffery with the partial revert patch.<br /> <br /> There are related issues that are also addressed in this series:<br /> <br /> * x86 page attribute logic, specifically Change Page Attributes (CPA),<br /> implements a feature whereby huge ranges can be collapsed into huge leaf<br /> entries. This can similarly cause a UAF when done in parallel with a<br /> ptdump walk, so similarly acquire the init_mm mmap lock to avoid this.<br /> <br /> * The CPA logic allows concurrent page table manipulation and CPA<br /> collapse, meaning the former risks accessing a page table the latter<br /> frees. Fix this by acquiring mmap write lock on init_mm across the<br /> whole CPA collapse operation and read lock on the page table<br /> manipulation.<br /> <br /> * x86 and arm64 permit walks of non-kernel mm&amp;#39;s (both allowing efi mm<br /> walks, and in x86&amp;#39;s case arbitrary mm&amp;#39;s), so we ensure kernel mappings<br /> remain stable by locking the init_mm as well as the mm being walked.<br /> <br /> The ordering of patches is established for both strict dependencies (the<br /> arm64 partial revert in particular has to be done after the vmap changes)<br /> and logical ones (the non-kernel mm fix only makes sense once the vmap/CPA<br /> fixes are in place).<br /> <br /> <br /> This patch (of 3):<br /> <br /> Currently there is a nasty ra<br /> ---truncated---