CVE-2026-97943: x86/mm/pat: Acquire init_mm write lock on collapse to avoid UAF
In the Linux kernel, the following vulnerability has been resolved:
x86/mm/pat: Acquire initmm write lock on collapse to avoid UAF
x86 implements page attribute modification using its Change Page Attributes (CPA) mechanism.
This tracks properties of ranges such as cache mode through x86 page attributes, and as part of that logic manipulates kernel page tables.
Since commit:
41d88484c71c ("x86/mm/pat: restore large ROX pages after fragmentation")
ranges of kernel page table entries can be collapsed into huge page table entries as part of this logic.
As part of this collapse, it frees the page tables which the collapsed entries previously pointed to, and it does so without any relevant locks being held to preclude concurrent kernel page table walkers.
The only way this code can be reached is if CPACOLLAPSE is specified, and this is only set in setmemoryrox() via:
setmemoryrox() -> changepageattrsetclr() -> cpaflush() -> cpacollapselargepages()
Notable users of this are execmem and BPF when manipulating executable mappings.
However, this is problematic for ptdump as it walks ranges it does not own and thus runs the risk of a use-after-free on page tables freed underneath it.
In addition, concurrent CPA collapse operations are possible which can also cause races.
Resolve the issue by acquiring the mmap write lock on initmm across the whole operation.
It is safe to acquire a sleeping lock as all the callers invoke setmemoryrox() from process context and in any case, changepageattrsetclr() calls vmunmapalias() which ultimately takes a mutex, disallowing atomic context here.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch 41d88484c71c
Event History
Frequently Asked Questions
Which systems are most likely to encounter this issue?
Systems that use x86 Change Page Attributes operations with set_memory_rox() are relevant. The description specifically identifies execmem and BPF as notable users when manipulating executable mappings, and ptdump is exposed because it can walk page-table ranges it does not own.
What concurrent activity is required for the use-after-free risk?
The vulnerable path must collapse page-table entries and free the previously referenced page tables while a concurrent kernel page-table walker accesses those ranges. ptdump is specifically called out as a walker that can encounter freed page tables.
Is the vulnerable collapse path used by every page-attribute change?
No. The collapse code is reachable only when CPA_COLLAPSE is specified; the description states that this flag is only set through set_memory_rox().
What is the remediation indicated by the available information?
Apply a Linux kernel update containing the fix that acquires the init_mm write lock during collapse. The provided stable kernel references identify fixes at commits 35820cf8dd521f5a651e221483015b0586794516, 93b98882198b15bd482da1fe8e84b05c7c3b3d83, and a1c7570cedd03372812a5b693732880867babbca.