CVE-2021-47639

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU<br /> <br /> Zap both valid and invalid roots when zapping/unmapping a gfn range, as<br /> KVM must ensure it holds no references to the freed page after returning<br /> from the unmap operation. Most notably, the TDP MMU doesn&amp;#39;t zap invalid<br /> roots in mmu_notifier callbacks. This leads to use-after-free and other<br /> issues if the mmu_notifier runs to completion while an invalid root<br /> zapper yields as KVM fails to honor the requirement that there must be<br /> _no_ references to the page after the mmu_notifier returns.<br /> <br /> The bug is most easily reproduced by hacking KVM to cause a collision<br /> between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug<br /> exists between kvm_mmu_notifier_invalidate_range_start() and memslot<br /> updates as well. Invalidating a root ensures pages aren&amp;#39;t accessible by<br /> the guest, and KVM won&amp;#39;t read or write page data itself, but KVM will<br /> trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing<br /> a zap of an invalid root _after_ the mmu_notifier returns is fatal.<br /> <br /> WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm]<br /> RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm]<br /> Call Trace:<br /> <br /> kvm_set_pfn_dirty+0xa8/0xe0 [kvm]<br /> __handle_changed_spte+0x2ab/0x5e0 [kvm]<br /> __handle_changed_spte+0x2ab/0x5e0 [kvm]<br /> __handle_changed_spte+0x2ab/0x5e0 [kvm]<br /> zap_gfn_range+0x1f3/0x310 [kvm]<br /> kvm_tdp_mmu_zap_invalidated_roots+0x50/0x90 [kvm]<br /> kvm_mmu_zap_all_fast+0x177/0x1a0 [kvm]<br /> set_nx_huge_pages+0xb4/0x190 [kvm]<br /> param_attr_store+0x70/0x100<br /> module_attr_store+0x19/0x30<br /> kernfs_fop_write_iter+0x119/0x1b0<br /> new_sync_write+0x11c/0x1b0<br /> vfs_write+0x1cc/0x270<br /> ksys_write+0x5f/0xe0<br /> do_syscall_64+0x38/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br />