CVE-2024-35877

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm/pat: fix VM_PAT handling in COW mappings<br /> <br /> PAT handling won&amp;#39;t do the right thing in COW mappings: the first PTE (or,<br /> in fact, all PTEs) can be replaced during write faults to point at anon<br /> folios. Reliably recovering the correct PFN and cachemode using<br /> follow_phys() from PTEs will not work in COW mappings.<br /> <br /> Using follow_phys(), we might just get the address+protection of the anon<br /> folio (which is very wrong), or fail on swap/nonswap entries, failing<br /> follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and<br /> track_pfn_copy(), not properly calling free_pfn_range().<br /> <br /> In free_pfn_range(), we either wouldn&amp;#39;t call memtype_free() or would call<br /> it with the wrong range, possibly leaking memory.<br /> <br /> To fix that, let&amp;#39;s update follow_phys() to refuse returning anon folios,<br /> and fallback to using the stored PFN inside vma-&gt;vm_pgoff for COW mappings<br /> if we run into that.<br /> <br /> We will now properly handle untrack_pfn() with COW mappings, where we<br /> don&amp;#39;t need the cachemode. We&amp;#39;ll have to fail fork()-&gt;track_pfn_copy() if<br /> the first page was replaced by an anon folio, though: we&amp;#39;d have to store<br /> the cachemode in the VMA to make this work, likely growing the VMA size.<br /> <br /> For now, lets keep it simple and let track_pfn_copy() just fail in that<br /> case: it would have failed in the past with swap/nonswap entries already,<br /> and it would have done the wrong thing with anon folios.<br /> <br /> Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():<br /> <br /> <br /> #include <br /> #include <br /> #include <br /> #include <br /> <br /> int main(void)<br /> {<br /> struct io_uring_params p = {};<br /> int ring_fd;<br /> size_t size;<br /> char *map;<br /> <br /> ring_fd = io_uring_setup(1, &amp;p);<br /> if (ring_fd