
Доказательство концепции для CVE-2025-39866 (UAF и гонка)
Автор: Byte Reaper
Этот POC пытается эксплуатировать уязвимость CVE-2025-39866, которая является дефектом в Linux-системах < 6.12.16 из-за отсутствия спинлока для потоков, что вызывает состояние гонки. Первый поток пытается использовать структуру wb, в то время как второй поток освобождает эту структуру, в результате первый поток работает со свободным указателем, что приводит к панике ядра системы. Идею эксплуатации уязвимости можно разделить на следующие этапы:
шаг 1: Создать поток 1 (главный PID)
- получить корневую dentry
- создать файл txt цели обратной записи
- создать структуру inode
- создать объект wb
- сохранить указатель wb в wb_old
Шаг 2:
- Создать поток 2 (kthread), который планирует рабочий элемент.
- Рабочий элемент запускает "inode_switch_wbs_work_fn", который обновляет "inode->i_wb" и планирует критическое освобождение через "wb_put_many".
Шаг 3:
- поток 2: освободить wb_old
- поток 1 -> указатель - освобождённый объект wb (освобождён старый)
-> доступ к освобождённому адресу -> крах ядра (segfault)
Linux x86_64
ядро linux < 6.12.16
1 - Он создал Makefile и включил эти команды для компиляции и сборки модуля ядра:
obj-m += exploit.o
KDIR := /usr/src/linux-headers-6.12.38+kali-amd64
PWD := $(shell pwd)
all:
make -C $(KDIR) M=$(PWD) modules
clean:
make -C $(KDIR) M=$(PWD) clean
# make clean
# make
1 - Вы найдёте файл с именем "exploit.ko", который является модулем ядра. Чтобы загрузить его в пространство ядра, используйте утилиту insmod:
# insmod exploit.ko
Основная проблема бага — отсутствие "спинлока" для синхронизации потоков. Решение здесь в следующем:
Во-первых (Slab/Slub Allocation), выделить отдельный slab/slub для каждого потока, чтобы ни один поток не мог управлять или манипулировать размером памяти другого потока.
Во-вторых (Синхронизация), настроить Workqueue, чтобы избежать взаимных помех и состояний гонки, где каждый поток завершает свою задачу и переходит к другому потоку вместо одновременного переключения WB или использования функции wb_wakeup_delayed.
В-третьих (HLE/RTM): Активация HLE/RTM в ядре зависит от архитектуры процессора, но если он поддерживает эти две функции, почему бы не использовать их в ядре, например, для управления потоком программы или при возникновении ошибки, пытаться откатиться к другому исключению вместо краха ("rollback") через инструкции XBEGIN, XABORT, XEN.
MIT