CVE-2022-50471

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen/gntdev: Accommodate VMA splitting<br /> <br /> Prior to this commit, the gntdev driver code did not handle the<br /> following scenario correctly with paravirtualized (PV) Xen domains:<br /> <br /> * User process sets up a gntdev mapping composed of two grant mappings<br /> (i.e., two pages shared by another Xen domain).<br /> * User process munmap()s one of the pages.<br /> * User process munmap()s the remaining page.<br /> * User process exits.<br /> <br /> In the scenario above, the user process would cause the kernel to log<br /> the following messages in dmesg for the first munmap(), and the second<br /> munmap() call would result in similar log messages:<br /> <br /> BUG: Bad page map in process doublemap.test pte:... pmd:...<br /> page:0000000057c97bff refcount:1 mapcount:-1 \<br /> mapping:0000000000000000 index:0x0 pfn:...<br /> ...<br /> page dumped because: bad pte<br /> ...<br /> file:gntdev fault:0x0 mmap:gntdev_mmap [xen_gntdev] readpage:0x0<br /> ...<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x46/0x5e<br /> print_bad_pte.cold+0x66/0xb6<br /> unmap_page_range+0x7e5/0xdc0<br /> unmap_vmas+0x78/0xf0<br /> unmap_region+0xa8/0x110<br /> __do_munmap+0x1ea/0x4e0<br /> __vm_munmap+0x75/0x120<br /> __x64_sys_munmap+0x28/0x40<br /> do_syscall_64+0x38/0x90<br /> entry_SYSCALL_64_after_hwframe+0x61/0xcb<br /> ...<br /> <br /> For each munmap() call, the Xen hypervisor (if built with CONFIG_DEBUG)<br /> would print out the following and trigger a general protection fault in<br /> the affected Xen PV domain:<br /> <br /> (XEN) d0v... Attempt to implicitly unmap d0&amp;#39;s grant PTE ...<br /> (XEN) d0v... Attempt to implicitly unmap d0&amp;#39;s grant PTE ...<br /> <br /> As of this writing, gntdev_grant_map structure&amp;#39;s vma field (referred to<br /> as map-&gt;vma below) is mainly used for checking the start and end<br /> addresses of mappings. However, with split VMAs, these may change, and<br /> there could be more than one VMA associated with a gntdev mapping.<br /> Hence, remove the use of map-&gt;vma and rely on map-&gt;pages_vm_start for<br /> the original start address and on (map-&gt;count live_grants atomic counter and/or the map-&gt;vma<br /> pointer (the latter of which is now removed). This prevents the<br /> userspace from mmap()&amp;#39;ing (with MAP_FIXED) a gntdev mapping over the<br /> same address range as a previously set up gntdev mapping. This scenario<br /> can be summarized with the following call-trace, which was valid prior<br /> to this commit:<br /> <br /> mmap<br /> gntdev_mmap<br /> mmap (repeat mmap with MAP_FIXED over the same address range)<br /> gntdev_invalidate<br /> unmap_grant_pages (sets &amp;#39;being_removed&amp;#39; entries to true)<br /> gnttab_unmap_refs_async<br /> unmap_single_vma<br /> gntdev_mmap (maps the shared pages again)<br /> munmap<br /> gntdev_invalidate<br /> unmap_grant_pages<br /> (no-op because &amp;#39;being_removed&amp;#39; entries are true)<br /> unmap_single_vma (For PV domains, Xen reports that a granted page<br /> is being unmapped and triggers a general protection fault in the<br /> affected domain, if Xen was built with CONFIG_DEBUG)<br /> <br /> The fix for this last scenario could be worth its own commit, but we<br /> opted for a single commit, because removing the gntdev_grant_map<br /> structure&amp;#39;s vma field requires guarding the entry to gntdev_mmap(), and<br /> the live_grants atomic counter is not sufficient on its own to prevent<br /> the mmap() over a pre-existing mapping.