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