When the KVM updates the guest's page table entry, it will first use get_user_pages_fast() to pin the page, and when it fails (e.g. the vma->flags has VM_IO or VM_PFNMAP), it will get corresponding VMA where the page lies in through find_vma_intersection(), calculate the physical address, and map the page to the kernel virtual address through memremap(), and finally, write the update.
The problem is that when we get the vma through find_vma_intersection(), only VM_PFNMAP is checked, not both VM_IO and VM_PFNMAP. In the reproducer below, after the KVM_SET_USER_MEMORY_REGION is completed, we replace the guest's memory mapping with the kernel-user shared region of io_uring and then perform the KVM_TRANSLATE operation, which finally triggers the page table entry update. Now, memremap() will return page_offset_base (direct mapping of all physical memory) + vaddr (the linear address of KVM_TRANSLATE) + vm_pgoff (the offset when io_uring performs mmap(2)), and use the return value as the base address for CMPXCHG (write 0x21 in this case). Since both vaddr and vm_pgoff are controllable by the user-mode process, writing may exceed the previously mapped guest memory space and trigger exceptions such as UAF. The vulnerability shares similarities with CVE-2021-22543.