byt3quester/cve-2022-22706-pocЭксплойт proof-of-concept для CVE-2022-22706: использует ошибку записи в page-cache драйвера ядра GPU Mali для изменения /etc/passwd в памяти и получения root-оболочки.
Драйвер GPU Arm Mali предоставляет пользовательскому пространству доступное для записи CPU-отображение страниц, которые он закрепил как доступные только для чтения, поэтому непривилегированный процесс получает записываемый алиас page cache файла, который он может открыть только с O_RDONLY.
exploit.c обнуляет поле пароля root в page cache файла /etc/passwd и запускает su root. Файл на диске никогда не изменяется.
PoC для дерева драйвера и цели QEMU в этом репозитории (
mali_kbaser35p0-01eac0,CONFIG_MALI_NO_MALI=y, x86_64 GKI 5.15). Запустите его в VM.
Два решения расходятся в том, кому разрешено записывать импортированные страницы.
Возможность записи CPU-отображения определяется флагом KBASE_REG_CPU_WR, но запрос закрепления (pin) запрашивает доступ на запись на основе только KBASE_REG_GPU_WR:
/* 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.
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: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.
gcc -static -o exploit exploit.c
Скопируйте его в VM и запустите от имени непривилегированного пользователя:
$ ./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 снова запрашивает пароль. Байты на диске не затрагивались.