CVE 2022-0847: Исследование уязвимости Dirty Pipe

Итак, как упоминалось выше, процесс может получить дескриптор файла, используя системный вызов sys_open. Если процесс хочет записать содержимое файла(или его часть) в канал, у него есть разные варианты сделать это. Он может производить операцию чтения(read()) данных из файла в буфер своей памяти(или mmap() файла), а затем записать(write()) их в канал. Однако весь этот процесс включает в себя три контекстных переключения в kernel-user-space. Чтобы вся эта операция выполнялась
более эффективно, ядро Linux использует системный вызов sys_splice. По сути, он выполняет копирование(на самом деле это является не совсем копированием, это можно будет увидеть ниже) из одного файлового дескриптора в другой в пространстве ядра. Как мы скоро увидим, в этом есть немалый смысл, поскольку содержимое файла или канала уже присутствует в памяти ядра в виде буфера, страницы или другой структуры. Либо fd_in, либо fd_out должен являтьcя каналом.

Другой «fd» может быть сокетом, файлом, блочным устройством, символьным устройством или другим каналом. Вы можете вновь обратиться к статье Макса Келлерманна, где показан пример того, как splicing используется для оптимизации ПО(и как это самое ПО привело к обнаружению описанной им ошибки :). Также полезным опытом будет прочтение данной статьи, в которой Линус Торвальдс объясняет работу системного вызова splice.

Реализация системного вызова splice

Идея реализации splice проиллюстрирована на рисунке ниже. После splicing’а и канал, и кеш страниц имеют разные представления одних и тех же данных в памяти.

Для того, чтобы убедиться, что представленная выше схема верна, мы начнем с точки входа системного вызова SYSCALL_DEFINE6(splice,…) и первым делом перейдем к функции __do_splice(), которая отвечает за копирование из userspace и в userspace. Вызываемая функция do_splice() определяет, что именно мы хотим сделать: присоединиться к каналу, установить соединение с/из/между каналами. В первом случае нижеприведенная функция вызывается:

static long do_splice_to(struct file *in, loff_t *ppos,
             struct pipe_inode_info *pipe, size_t len,
             unsigned int flags);

и выполняет:

in->f_op->splice_read(in, ppos, pipe, len, flags);

source

С этого момента, execution path зависит от типа файла, который мы хотим “соединить” с каналом. Поскольку нашей целью является обычный файл, а имеющаяся виртуальная машина использует файловую систему ext2, реализация системного вызова splice находится в ext2_file_operations.

const struct file_operations ext2_file_operations = {
...
    .read_iter      = ext2_file_read_iter,
...
    .splice_read    = generic_file_splice_read,
...
};

source

Примечание: если у вас есть желание, вы можете более подробно разобраться Linux VFS, которая хорошо описана в официальной документации к Linux.

Вызов generic_file_splice_read() наконец приводит нас к filemap_read(). Заметьте, что в этот момент мы переключаемся с файловой системы fs/ на подсистему управления памятью ядра(memory managment subsystem of the kernel) mm/. Дополнительно.

copied = copy_folio_to_iter(folio, offset, bytes, iter);

pause_for_inspection("About to write() into page cache");
if (write(pipefds[1], "pwned by user", 13) != 13) {
    exit(1);
}

user@lkd-debian-qemu:~$ ./poc
user@lkd-debian-qemu:~$ cat target_file
File pwned by user!
user@lkd-debian-qemu:~$ exit
root@lkd-debian-qemu:~# echo 1 > /proc/sys/vm/drop_caches
[  232.397273] bash (203): drop_caches: 1
root@lkd-debian-qemu:~# su user
user@lkd-debian-qemu:~$ cat target_file
File owned by root