Contents #
- Introduction
- Background
- How file I/O works in linux kernel
- Linux pipe
- Splice system call
- Root Cause Analysis
- Exploit
- Patch
- References
Introduction #
Dirty pipe 취약점은 Max Kalleramnn이 고객사 문의를 해결하는 과정에서 발견한 취약점으로, 리눅스 커널 내부에서 새로운 파이프 버퍼가 할당될 때 적절한 초기화 작업이 수행되지 않아 발생하였다[6, 9].
파이프는 단방향 데이터 채널로, 프로세스 간 데이터 통신에 사용될 수 있다. 리눅스 커널은 이를 파이프 버퍼의 ring (FIFO)로 구현하며, 각 파이프 버퍼는 페이지를 참조하여 데이터를 읽거나 쓸 수 있다. 이때 user space와 kernel space 간 데이터 복사 과정에서 발생하는 overhead를 줄이기 위해 5274f052e7b3 커밋 [8]에서 splice system call이 제안되었다[2, 6, 7].
Splice system call는 페이지의 데이터를 복사하는 것이 아닌, 페이지를 참조하는 포인터를 추가하는 방식으로 데이터를 이동시킨다. 이때 f6dd975583bd 커밋 [10] 이후에는 해당 페이지에 이미 데이터가 존재한다면, write system call은 파이프 버퍼 구조체의 flag 멤버 변수의 값을 확인한다. 그리고 PIPE_BUF_FLAG_CAN_MERGE가 셋트되어 있다면 페이지에 데이터를 추가한다[4, 6].
그런데 데이터가 추가되는 페이지가 파이프가 소유하는 페이지가 아니라면, 파이프가 아닌 다른 파일에 데이터가 복사될 수 있다[6].
Background #
그럼 이제 리눅스 커널에서 파일 입출력이 어떻게 동작하는지, 그리고 파이프와 splice system call이 어떻게 동작하는지 좀 더 세부적으로 알아보겠다.
How file I/O works in linux kernel #
리눅스 커널은 사용자가 read 또는 write system call이 호출하면 일반적으로 (generic) 검사해야 하는 사항들을 확인한다. 그리고 해당 파일 시스템의 read 또는 write 함수를 호출한다. 파일 시스템의 함수는 파일을 읽거나 쓸 때 검사해야 하는 사항들을 검사하고 페이지 캐시에 데이터를 읽거나 쓰기 위한 함수를 호출한다. 이 과정은 다음과 같은 함수 콜 트레이스 예시 (파일 쓰기 연산)로부터 알 수 있다:
1write()
2ksys_write()
3vfs_write()
4 rw_verfiy_area()
5 new_sync_write()
6call_write_iter()
7file->f_op->write_iter() /* Here, we think this as ext4_file_write_iter() */
8 /* f_op is assigned when open system call */
9ext4_buffered_write_iter()
10generic_perform_write() /* Write data to page cache and mark as dirty */
이렇게 리눅스 커널은 파일을 읽고 쓸 때 페이지 캐시를 사용하여 상대적으로 비싼 비용을 치러야 하는 디스크 연산을 피한다. 즉, 파일로부터 데이터를 읽을 때는 먼저 디스크로부터 페이지 캐시에 데이터를 넣고 그 이후의 읽기 연산에서는 디스크가 아닌 페이지 캐시로부터 읽어들인다. 이는 파일에 데이터를 쓸 때도 적용되는데, 먼저 페이지 캐시에 데이터를 쓰고 해당 페이지에 dirty 표시를 한 후에 해당 데이터를 다른 프로세스가 참조할 때 디스크에 쓰는 것이다[3].
Linux pipe and splice system call #
리눅스 커널에서 파이프는 파이프 파일 시스템에 속한 파일로 다루어진다. 따라서 파이프 파일을 연 후에 write system call을 호출하면 pipe_write 함수가 호출될 것이다. 그 이유는 파이프 파일 시스템의 file_operations가 다음과 같이 구현되어 있기 때문이다 (path: fs/pipe.c):
1const struct file_operations pipefifo_fops = {
2 .open = fifo_open,
3 .llseek = no_llseek,
4 .read_iter = pipe_read,
5 .write_iter = pipe_write,
6 .poll = pipe_poll,
7 .unlocked_ioctl = pipe_ioctl,
8 .release = pipe_release,
9 .fasync = pipe_fasync,
10};
이러한 파이프는 내부적으로 파이프 버퍼의 ring (FIFO)로 구현되며, 각각의 버퍼는 데이터를 읽거나 쓰기 위한 페이지를 참조한다 (path: include/linux/pipe_fs_i.h).
+--> bufs: [0] <-------------head, tail<-+
| +---> page | |
| [1] V |
| +---> page | |
| [2] V |
| +---> page | |
| [...] V |
| +---> page +------+
|
+--> tmp_page
|
|
pipe_inode_info
위 그림에서 head는 다음에 할당될 파이프 버퍼에 대한 인덱스이고, tail은 다음에 사용될 파이프 버퍼에 대한 인덱스이다. 이러한 파이프 버퍼는 다음과 같이 코드상에서 구현된다:
1/**
2 * struct pipe_buffer - a linux kernel pipe buffer
3 * @page: the page containing the data for the pipe buffer
4 * @offset: offset of data inside the @page
5 * @len: length of data inside the @page
6 * @ops: operations associated with this buffer. See @pipe_buf_operations.
7 * @flags: pipe buffer flags. See above.
8 * @private: private data owned by the ops.
9 **/
10struct pipe_buffer {
11 struct page *page;
12 unsigned int offset, len;
13 const struct pipe_buf_operations *ops;
14 unsigned int flags;
15 unsigned long private;
16};
지금까지 설명한 것을 종합하면 파이프에 데이터를 쓰는 과정은 다음과 같을 것이라고 생각해볼 수 있다:
1. user calls write system call
2. pipe_write() is called by call_write_iter()
3. data is transferred from write end pipe to read end pipe
그리고 다음 코드의 (1)로부터 PIPE_BUF_FLAG_CAN_MERGE가 셋트되어 있다면 데이터를 기 존재하는 페이지에 추가할 것임을 알 수 있다:
1static ssize_t
2pipe_write(struct kiocb *iocb, struct iov_iter *from)
3{
4 struct file *filp = iocb->ki_filp;
5 struct pipe_inode_info *pipe = filp->private_data;
6 unsigned int head;
7 ssize_t ret = 0;
8 size_t total_len = iov_iter_count(from);
9 ssize_t chars;
10 bool was_empty = false;
11 bool wake_next_writer = false;
12
13 /* Null write succeeds. */
14 if (unlikely(total_len == 0))
15 return 0;
16
17 __pipe_lock(pipe);
18
19 if (!pipe->readers) {
20 send_sig(SIGPIPE, current, 0);
21 ret = -EPIPE;
22 goto out;
23 }
24
25 /* ... */
26
27 head = pipe->head;
28 was_empty = pipe_empty(head, pipe->tail);
29 chars = total_len & (PAGE_SIZE-1);
30 if (chars && !was_empty) {
31 unsigned int mask = pipe->ring_size - 1;
32 struct pipe_buffer *buf = &pipe->bufs[(head - 1) & mask];
33 int offset = buf->offset + buf->len;
34
35 if ((buf->flags & PIPE_BUF_FLAG_CAN_MERGE) &&
36 offset + chars <= PAGE_SIZE) {
37 ret = pipe_buf_confirm(pipe, buf);
38 if (ret)
39 goto out;
40
41 ret = copy_page_from_iter(buf->page, offset, chars, from); /* (1) */
42 if (unlikely(ret < chars)) {
43 ret = -EFAULT;
44 goto out;
45 }
46
47 buf->len += ret;
48 if (!iov_iter_count(from))
49 goto out;
50 }
51 }
52
53 for (;;) {
54 if (!pipe->readers) {
55 send_sig(SIGPIPE, current, 0);
56 if (!ret)
57 ret = -EPIPE;
58 break;
59 }
60
61 head = pipe->head;
62 if (!pipe_full(head, pipe->tail, pipe->max_usage)) {
63 unsigned int mask = pipe->ring_size - 1;
64 struct pipe_buffer *buf = &pipe->bufs[head & mask];
65 struct page *page = pipe->tmp_page;
66 int copied;
67
68 /* ... */
69
70 if (is_packetized(filp))
71 buf->flags = PIPE_BUF_FLAG_PACKET;
72 else /* (2) */
73 buf->flags = PIPE_BUF_FLAG_CAN_MERGE;
74
75 /* ... */
76 }
77
78 /* ... */
79 }
80
81 /* ... */
82}
그럼 PIPE_BUF_FLAG_CAN_MERGE는 어떤 상황에서 셋트될까? 위 코드의 (2)를 보면 파이프의 파일 구조체가 packetize되지 않은 경우에 셋트함을 알 수 있다. 그리고 파이프에 대한 manpage를 살펴보면 파이프를 열 때 O_DIRECT를 셋트한 경우에 packet mode로 동작함을 알 수 있다. 따라서 O_DIRECT를 셋트하지 않고 파이프를 연다면 PIPE_BUF_FLAG_CAN_MERGE가 셋트될 것이다[2].
Splice system call #
Splice system call은 파이프를 사용하여 데이터 통신을 수행할 때 user space와 kernel space 간 데이터 복사로 인해 발생하는 overhead를 줄이기 위해 제안되었다. 그러나 파이프 파일 간에만 사용되는 것은 아니며, file-to-pipe, pipe-to-file, pipe-to-pipe에 사용될 수 있다. 이때 overhead를 줄이는 방식은 복사하고자 하는 데이터가 존재하는 페이지에 대한 참조를 추가하는 것 (또는, refcount를 증가시키는 것)이다[4, 8].
splice between file and pipe:
+-----> [page] <----+
| |
| |
page cache pipe buffer
splice between pipe and pipe:
+-----> [page] <----+
| |
| |
ipipe buffer opipe buffer
다음 코드의 (1), (2)는 이를 잘 나타낸다:
1/*
2 * Splice contents of ipipe to opipe.
3 */
4static int splice_pipe_to_pipe(struct pipe_inode_info *ipipe,
5 struct pipe_inode_info *opipe,
6 size_t len, unsigned int flags)
7{
8 struct pipe_buffer *ibuf, *obuf;
9 unsigned int i_head, o_head;
10 unsigned int i_tail, o_tail;
11 unsigned int i_mask, o_mask;
12 int ret = 0;
13 bool input_wakeup = false;
14
15retry:
16 ret = ipipe_prep(ipipe, flags);
17 if (ret)
18 return ret;
19
20 ret = opipe_prep(opipe, flags);
21 if (ret)
22 return ret;
23
24 /*
25 * Potential ABBA deadlock, work around it by ordering lock
26 * grabbing by pipe info address. Otherwise two different processes
27 * could deadlock (one doing tee from A -> B, the other from B -> A).
28 */
29 pipe_double_lock(ipipe, opipe);
30
31 i_tail = ipipe->tail;
32 i_mask = ipipe->ring_size - 1;
33 o_head = opipe->head;
34 o_mask = opipe->ring_size - 1;
35
36 do {
37 /* ... */
38
39 ibuf = &ipipe->bufs[i_tail & i_mask];
40 obuf = &opipe->bufs[o_head & o_mask];
41
42 if (len >= ibuf->len) {
43 /*
44 * Simply move the whole buffer from ipipe to opipe
45 */
46 *obuf = *ibuf; /* (1) */
47
48 /* ... */
49 } else {
50 /* ... */
51
52 *obuf = *ibuf;
53
54 /* ... */
55 }
56
57 /* ... */
58 } while (len);
59
60 /* ... */
61}
1static size_t copy_page_to_iter_pipe(struct page *page, size_t offset, size_t bytes,
2 struct iov_iter *i)
3{
4 /* ... */
5 off = i->iov_offset;
6 buf = &pipe->bufs[i_head & p_mask];
7 if (off) { /* (3) */
8 if (offset == off && buf->page == page) {
9 /* merge with the last one */
10 buf->len += bytes;
11 i->iov_offset += bytes;
12 goto out;
13 }
14 i_head++;
15 buf = &pipe->bufs[i_head & p_mask];
16 }
17 if (pipe_full(i_head, p_tail, pipe->max_usage))
18 return 0;
19
20 buf->ops = &page_cache_pipe_buf_ops;
21 get_page(page); /* increases refcount of argument page */
22 buf->page = page; /* (2) */
23 buf->offset = offset;
24 buf->len = bytes;
25
26 /* ... */
27}
위 코드의 (2)에서 get_page()는 인자로 전달된 페이지의 refcount를 증가시키는 함수임에 주목하라. 이는 copy_page_to_iter_pipe()에 전달된 page와 (2)의 page가 같음을 의미한다. 즉, file-to-pipe에서 파일의 페이지 캐싱을 위해 할당된 페이지를 파이프 버퍼의 page 멤버 변수가 참조한다는 것이다. 그럼 위 코드의 (3)이 가리키는 if 문에서 마지막 것과 병합하는 코드가 그 이후에 실행될 수 있다.
Root Cause Analysis #
다시 splice system call을 살펴보면 file-to-pipe의 경우에 다음과 같은 함수 콜 트레이스를 거쳐서
splice()
do_splice()
do_splice_to()
do_splice_to()가 호출됨을 확인할 수 있다.
1/*
2 * Attempt to initiate a splice from a file to a pipe.
3 */
4static long do_splice_to(struct file *in, loff_t *ppos,
5 struct pipe_inode_info *pipe, size_t len,
6 unsigned int flags)
7{
8 int ret;
9
10 if (unlikely(!(in->f_mode & FMODE_READ)))
11 return -EBADF;
12
13 ret = rw_verify_area(READ, in, ppos, len);
14 if (unlikely(ret < 0))
15 return ret;
16
17 if (unlikely(len > MAX_RW_COUNT))
18 len = MAX_RW_COUNT;
19
20 if (in->f_op->splice_read)
21 return in->f_op->splice_read(in, ppos, pipe, len, flags);
22 return default_file_splice_read(in, ppos, pipe, len, flags);
23}
이때 해당 파일이 ext4 파일 시스템에 속하는 파일이라고 가정하면, 다음과 같은 함수 콜 트레이스를 거쳐서
file->f_op->splice_read() /* this is generic_file_splice_read() */
call_read_iter()
file->f_op->read_iter()
ext4_file_read_iter()
generic_file_read_iter()
generic_file_buffered_read()
copy_page_to_iter()
copy_page_to_iter_pipe()
copy_page_to_iter_pipe()가 호출됨을 알 수 있다. 이때 이 함수의 코드는 다음과 같다:
1static size_t copy_page_to_iter_pipe(struct page *page, size_t offset, size_t bytes,
2 struct iov_iter *i)
3{
4 struct pipe_inode_info *pipe = i->pipe;
5 struct pipe_buffer *buf;
6 unsigned int p_tail = pipe->tail;
7 unsigned int p_mask = pipe->ring_size - 1;
8 unsigned int i_head = i->head;
9 size_t off;
10
11 if (unlikely(bytes > i->count))
12 bytes = i->count;
13
14 if (unlikely(!bytes))
15 return 0;
16
17 if (!sanity(i))
18 return 0;
19
20 off = i->iov_offset;
21 buf = &pipe->bufs[i_head & p_mask];
22 if (off) {
23 if (offset == off && buf->page == page) {
24 /* merge with the last one */
25 buf->len += bytes;
26 i->iov_offset += bytes;
27 goto out;
28 }
29 i_head++;
30 buf = &pipe->bufs[i_head & p_mask];
31 }
32 if (pipe_full(i_head, p_tail, pipe->max_usage))
33 return 0;
34
35 /****** (1) ******/
36 buf->ops = &page_cache_pipe_buf_ops;
37 get_page(page); /* increases refcount of argument page */
38 buf->page = page;
39 buf->offset = offset;
40 buf->len = bytes;
41
42 pipe->head = i_head + 1;
43 i->iov_offset = offset + bytes;
44 i->head = i_head;
45out:
46 i->count -= bytes;
47 return bytes;
48}
위 코드의 (1) 이하의 코드를 살펴보면 파이프 버퍼 구조체의 flag 멤버 변수에 대한 초기화가 없음을 알 수 있다. 즉, 위 함수를 통해 할당된 파이프 버퍼는 그 이전에 셋트된 flag 값을 (e.g., PIPE_BUF_FLAG_CAN_MERGE) 그대로 따라간다는 것이다.
PoC: Exploit #
References #
- Max Kallermann, "lib/iov_iter: initialize flags in new pipe_buffer," 2022. [Online]. Available: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/lib/iov_iter.c?id=9d2231c5d74e13b2a0546fee6737ee4446017903, [Accessed Sep. 07, 2023].
- "pipe(2) -- Linux manual page," 2023. [Online]. Available: https://man7.org/linux/man-pages/man2/pipe.2.html, [Accessed Sep. 07, 2023].
- "Linux memory management." [Online]. Available: https://www.kernel.org/doc/html/latest/admin-guide/mm/concepts.html#page-cache, [Accessed Sep. 07, 2023].
- "splice(2) -- Linux manual page," 2023. [Online]. Available: https://man7.org/linux/man-pages/man2/splice.2.html, [Accessed Sep. 07, 2023].
- hyeyoo, "Page Cache: filemap_read", 2022. [Online]. Available: https://hyeyoo.com/161, [Accessed Sep. 07, 2023].
- Max Kallermann, "The Dirty Pipe Vulnerability," 2022. [Online]. Available: https://dirtypipe.cm4all.com/, [Accessed Sep. 08, 2023].
- Jonathan Corbet, "Rethinking splice()," 2023. [Online]. Available: https://lwn.net/Articles/923237/, [Accessed Jan. 21, 2024].
- Jens Axboe,"[PATCH] Introduce sys_splice() system call," 2006. [Online]. Available: https://github.com/torvalds/linux/commit/5274f052e7b3dbd81935772eb551dfd0325dfa9d, [Accessed Jan. 21, 2024].
- "CVE-2022-0847 Detail," NIST. [Online]. Available: https://nvd.nist.gov/vuln/detail/cve-2022-0847, [Accessed Jan. 21, 2024].
- Christoph Hellwig, "pipe: merge anon_pipe_buf*_ops," 2020. [Online]. Available: https://github.com/torvalds/linux/commit/f6dd975583bd8ce088400648fd9819e4691c8958, [Accessed Jan. 21, 2024].