## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-BYT3QUESTER-CVE-2022-22706-POC
# CVE-2022-22706 - Запись в page cache
Драйвер GPU Arm Mali предоставляет пользовательскому пространству доступное для записи CPU-отображение страниц, которые он закрепил как доступные только для чтения, поэтому непривилегированный процесс получает записываемый алиас page cache файла, который он может открыть только с `O_RDONLY`.
`exploit.c` обнуляет поле пароля root в page cache файла `/etc/passwd` и запускает `su root`. Файл на диске никогда не изменяется.
> PoC для дерева драйвера и цели QEMU в этом репозитории (`mali_kbase` **r35p0-01eac0** , `CONFIG_MALI_NO_MALI=y`, x86_64 GKI 5.15). Запустите его в VM.
## Суть ошибки
Два решения расходятся в том, кому разрешено записывать импортированные страницы.
Возможность записи CPU-отображения определяется флагом `KBASE_REG_CPU_WR`, но запрос закрепления (pin) запрашивает доступ на запись на основе только `KBASE_REG_GPU_WR`:
root@kitploit:~
/* mali_kbase_mem.c */
pinned_pages = pin_user_pages_remote(
mm, address, alloc->imported.user_buf.nr_pages,
reg->flags & KBASE_REG_GPU_WR ? FOLL_WRITE : 0, pages, NULL, NULL);
Импортируйте с установленным `CPU_WR` и сброшенным `GPU_WR` — и вы получите обе половины сразу: записываемое CPU-отображение импорта и пин через `get_user_pages`, взятый без `FOLL_WRITE`. Без `FOLL_WRITE` функция `get_user_pages` никогда не нарушает COW на отображении файла, доступном только для чтения, и возвращает саму страницу page cache. Затем драйвер отображает эти самые страницы обратно в пользовательское пространство как записываемые.
Исправлено в `5381ff7` («GPUCORE-32592 Fix userbuf imports to respect RO memory»), где доступ на запись определяется по `KBASE_REG_CPU_WR | KBASE_REG_GPU_WR`, а не только по `GPU_WR`.
## Схема работы эксплойта
root@kitploit:~
sequenceDiagram
participant U as unprivileged process
participant K as mali_kbase
participant PC as page cache
U->>U: mmap /etc/passwd O_RDONLY, PROT_READ
U->>K: MEM_IMPORT(anon page, CPU_RD|CPU_WR|GPU_RD)
Note over K: address recorded, nothing pinned yet
U->>U: munmap(anon) + mremap file mapping onto that VA
U->>K: mmap(import cookie) → writable CPU mapping
U->>K: JOB_SUBMIT(EXTERNAL_RESOURCES)
K->>PC: pin_user_pages_remote() without FOLL_WRITE
U->>PC: memcpy() through the writable mapping
U->>U: execl("/bin/su", "su", "root")
`MEM_IMPORT` лишь запоминает адрес; закрепление происходит позже, при `JOB_SUBMIT`. Именно этот зазор позволяет в промежутке подменить анонимную страницу отображением файла.
Правка сохраняет длину строки, поэтому всё после строки root не сдвигается:
root@kitploit:~
root:x:0:0:root:/root:/bin/sh ← before
root::0:0:rootx:/root:/bin/sh ← after (empty password)
busybox `su` возвращает `CHECKPASS_PW_HAS_EMPTY_PASSWORD` до запроса пароля, когда поле пароля пустое, и читает `/etc/shadow`, только когда оно равно `x`.
## Сборка и запуск
root@kitploit:~
gcc -static -o exploit exploit.c
Скопируйте его в VM и запустите от имени непривилегированного пользователя:
root@kitploit:~
$ ./exploit
## Демонстрация
Запись сделана по SSH внутри цели QEMU под пользователем `user` (uid 1000). `./exploit` изменяет строку root в page cache файла `/etc/passwd` и запускает `su root`, который сразу даёт root-оболочку без запроса пароля.
Если выйти из этой оболочки и снова запустить `su`, root по-прежнему будет получен: страница остаётся закэшированной, поэтому каждый последующий `open()`/`read()` файла `/etc/passwd` видит изменённые байты.
После того как `echo 1 > /proc/sys/vm/drop_caches` вытесняет страницу и файл заново считывается с хранилища, `su` снова запрашивает пароль. Байты на диске не затрагивались.
## Ссылки
* Arm — уязвимости драйвера GPU Mali
* STAR Labs — Mali-cious Intent: эксплуатация уязвимостей GPU (CVE-2022-22706 / CVE-2021-39793)
* Исправление в апстриме — `5381ff7`