In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
KVM: x86\/mmu: Consume the locked rmap value in the lockless rmap walk<\/p>\n
__kvm_rmap_lock() deliberately elides the rmap lock when it observes an
\nempty rmap. In that case kvm_rmap_lock_readonly() also re-enables
\npreemption and returns zero, so the caller holds neither the rmap lock
\nnor a preemption reference. The elision documents the invariant it
\nrelies on:<\/p>\n
\t * Elide the lock if the rmap is empty, as lockless walkers (read-only
\n\t * mode) don’t need to (and can’t) walk an empty rmap, nor can they add
\n\t * entries to the rmap. I.e. the only paths that process empty rmaps
\n\t * do so while holding mmu_lock for write, and are mutually exclusive.<\/p>\n
kvm_rmap_age_gfn_range() ignores the returned value and unconditionally
\nenters for_each_rmap_spte_lockless(). The iterator started with
\nrmap_get_first(), which re-reads rmap_head->val rather than using the
\nvalue returned by the lock. If a writer populates the rmap between the
\nlock’s read and the iterator’s re-read, the aging path walks the newly
\ninstalled rmap without holding its lock.<\/p>\n
For a KVM_RMAP_MANY rmap this leaves the walker following a
\npte_list_desc chain that it never locked. A writer holding mmu_lock for
\nwrite may free that chain (e.g. kvm_zap_all_rmap_sptes() on the recycle
\npath, or any rmap zap) via kmem_cache_free() while the walk is in
\nprogress, giving a slab use-after-free. Nothing serialises the two: the
\naging path runs without mmu_lock when CONFIG_KVM_MMU_LOCKLESS_AGING=y,
\nand the rmap lock that would otherwise exclude the writer was elided.
\nBecause the empty path re-enables preemption, the interval between the
\ntwo reads can span an arbitrary scheduling delay.<\/p>\n
Fix the class of bug by having the lockless walk consume the value
\nreturned by the lock instead of re-reading the rmap. Split
\nrmap_get_first() into __rmap_get_first(), which starts an iterator from
\nan already-read rmap value, and make for_each_rmap_spte_lockless() take
\nthat value and call __rmap_get_first() directly.
\nkvm_rmap_age_gfn_range() passes the value returned by
\nkvm_rmap_lock_readonly(): when the lock was elided the value is zero,
\n__rmap_get_first() returns NULL, and the walk is skipped. No lockless
\nwalker re-reads the rmap, so the lock-elision invariant cannot be
\nviolated, and no lock()-without-paired-unlock() path is added to the
\naging code.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
KVM: x86\/mmu: Consume the locked rmap value in the lockless rmap walk<\/p>\n
__kvm_rmap_lock() deliberately elides the rmap lock when it <\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-24615","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/24615","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=24615"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=24615"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=24615"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}