CVE-2024-47674

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: avoid leaving partial pfn mappings around in error case<br /> <br /> As Jann points out, PFN mappings are special, because unlike normal<br /> memory mappings, there is no lifetime information associated with the<br /> mapping - it is just a raw mapping of PFNs with no reference counting of<br /> a &amp;#39;struct page&amp;#39;.<br /> <br /> That&amp;#39;s all very much intentional, but it does mean that it&amp;#39;s easy to<br /> mess up the cleanup in case of errors. Yes, a failed mmap() will always<br /> eventually clean up any partial mappings, but without any explicit<br /> lifetime in the page table mapping itself, it&amp;#39;s very easy to do the<br /> error handling in the wrong order.<br /> <br /> In particular, it&amp;#39;s easy to mistakenly free the physical backing store<br /> before the page tables are actually cleaned up and (temporarily) have<br /> stale dangling PTE entries.<br /> <br /> To make this situation less error-prone, just make sure that any partial<br /> pfn mapping is torn down early, before any other error handling.