In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
mm\/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish<\/p>\n
On arm64 server, we find that a task trying to grab the anon_vma lock
\ntriggers hungtask.<\/p>\n
INFO: task main:2354726 blocked for more than 120 seconds.
\n Tainted: G E 5.10.0-0021.aarch64 #1
\n“echo 0 > \/proc\/sys\/kernel\/hung_task_timeout_secs” disables this message.
\ntask:main state:D stack: 0 pid:2354726 ppid:2350673 flags:0x00000a01
\nCall trace:
\n __switch_to+0x7c\/0xbc
\n __schedule+0x3b4\/0x8a0
\n schedule+0x50\/0xe0
\n rwsem_down_write_slowpath+0x3cc\/0x6cc
\n down_write+0x60\/0x260
\n __anon_vma_prepare+0x6c\/0x210
\n do_anonymous_page+0x258\/0x660
\n handle_pte_fault+0x188\/0x214
\n __handle_mm_fault+0x1b0\/0x380
\n handle_mm_fault+0xf4\/0x284
\n do_page_fault+0x19c\/0x494
\n do_translation_fault+0xcc\/0xf8
\n do_mem_abort+0x48\/0xac
\n el0_da+0x44\/0x80
\n el0_sync_handler+0x88\/0xb4
\n el0_sync+0x160\/0x180<\/p>\n
After analyzing the vmcore, we found the anon_vma->root->rwsem.count is
\n-1. There is another anon_vma whose anon_vma->root->rwsem.count is 1, the
\nanon_vma->root->rwsem.owner shows the lock is held, but the stack of the
\ntask shows the task doesn’t hold the anon_vma lock.<\/p>\n
After adding more debugging info, we found __anon_vma_prepare() reuses
\nanon_vma and triggers the UAF of anon_vma->root due to missing memory
\nbarrier, leading to locking and unlocking two different anon_vma->root,
\nthus leading to an anon_vma will never be unlocked, and another anon_vma
\ncouldn’t be locked anymore.<\/p>\n
This race requires two adjacent VMAs that are not merged but are
\nanon_vma-compatible (e.g., they differ in VMA_ACCESS_FLAGS that can be
\nchanged by mprotect()). Two threads fault on each VMA concurrently, both
\ncalling __anon_vma_prepare() with only mmap_lock held for reading.<\/p>\n
THREAD A THREAD B
\n__anon_vma_prepare __anon_vma_prepare
\n find_mergeable_anon_vma() -> NULL
\n anon_vma = anon_vma_alloc();
\n anon_vma->root = anon_vma;
\n \/\/ the two stores may be reordered
\n vma->anon_vma = anon_vma;
\n \/\/ finds A’s anon_vma
\n anon_vma = find_mergeable_anon_vma(vma);
\n anon_vma_lock_write(anon_vma);
\n \/\/ may still see the old root
\n down_write(&anon_vma->root->rwsem);
\n anon_vma_unlock_write(anon_vma);
\n \/\/ see the new root, never unlock old
\n up_write(&anon_vma->root->rwsem);<\/p>\n
thread A triggers page fault and calls __anon_vma_prepare() to prepare
\nanon_vma for the faulting vma. __anon_vma_prepare() allocates and
\ninitializes a new anon_vma, and then publishes it to the vma with a plain
\nstore. anon_vma_prepare() only requires the mmap_lock to be held for
\nreading, so two threads can fault on adjacent VMAs at the same time.
\nWhile thread A publishes a new anon_vma, thread B could find the anon_vma
\nvia find_mergeable_anon_vma() and then locks anon_vma->root->rwsem.<\/p>\n
The store to anon_vma->root in anon_vma_alloc() and the store to
\nvma->anon_vma can be reordered. The anon_vma_lock_write() and spin_lock()
\nonly provide acquire semantics, which do not prevent prior stores from
\nbeing reordered after them. The release semantics of the corresponding
\nspin_unlock() and anon_vma_unlock_write() come too late, the store to
\nvma->anon_vma is already published before they take effect. As a result,
\nthread B can observe the following order:<\/p>\n
vma->anon_vma = anon_vma;
\n anon_vma->root = anon_vma;<\/p>\n
The anon_vma slab is SLAB_TYPESAFE_BY_RCU, so a newly allocated anon_vma
\nmay reuse memory from a previously freed one. The constructor
\n(anon_vma_ctor) does not reset anon_vma->root, and __put_anon_vma()
\ndoesn’t clear it either, so the old root value persists until
\nanon_vma_alloc() overwrites it. If that store isn’t v
\n—truncated—<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
mm\/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish<\/p>\n
On arm64 server, we find that a task trying to grab t<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-40979","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/40979","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=40979"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=40979"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=40979"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}