CVE-2024-38610

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()<br /> <br /> Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes".<br /> <br /> Patch #1 fixes a bunch of issues I spotted in the acrn driver. It<br /> compiles, that&amp;#39;s all I know. I&amp;#39;ll appreciate some review and testing from<br /> acrn folks.<br /> <br /> Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding<br /> more sanity checks, and improving the documentation. Gave it a quick test<br /> on x86-64 using VM_PAT that ends up using follow_pte().<br /> <br /> <br /> This patch (of 3):<br /> <br /> We currently miss handling various cases, resulting in a dangerous<br /> follow_pte() (previously follow_pfn()) usage.<br /> <br /> (1) We&amp;#39;re not checking PTE write permissions.<br /> <br /> Maybe we should simply always require pte_write() like we do for<br /> pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let&amp;#39;s check for<br /> ACRN_MEM_ACCESS_WRITE for now.<br /> <br /> (2) We&amp;#39;re not rejecting refcounted pages.<br /> <br /> As we are not using MMU notifiers, messing with refcounted pages is<br /> dangerous and can result in use-after-free. Let&amp;#39;s make sure to reject them.<br /> <br /> (3) We are only looking at the first PTE of a bigger range.<br /> <br /> We only lookup a single PTE, but memmap-&gt;len may span a larger area.<br /> Let&amp;#39;s loop over all involved PTEs and make sure the PFN range is<br /> actually contiguous. Reject everything else: it couldn&amp;#39;t have worked<br /> either way, and rather made use access PFNs we shouldn&amp;#39;t be accessing.