bytereaper77/cve-2025-39866Prova de conceito para CVE-2025-39866 (UAF e condição de corrida)
Autor: Byte Reaper
Este POC tenta explorar a vulnerabilidade CVE-2025-39866, que é uma falha em sistemas Linux < 6.12.16 devido à falta de um spinlock para threads, causando uma condição de corrida. A primeira thread tenta usar a struct wb enquanto a thread 2 libera essa estrutura, fazendo com que a primeira thread lide com um ponteiro liberado, levando a um kernel panic no sistema. Podemos dividir a ideia de explorar a vulnerabilidade nas seguintes etapas:
step 1 : Create thread 1 "main pid"
- get root dentry
- create file txt writeback target
- create strcut inode
- Create object wb
- save pointer wb in wb_old
Step 2:
- Create Thread 2 (kthread) that schedules a work item.
- The work item runs “inode_switch_wbs_work_fn” which updates “inode->i_wb” and schedules the critical free via “wb_put_many”.
step 3 :
- thread 2 : free wb_olb
- thread 1 -> pointer - free object wb (free old)
-> access free address -> crash kernel (segfault)
Linux x86_64
kernel linux < 6.12.16
1 - He created a Makefile and included these commands to compile and build the kernel module:
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 - You will find a file named "exploit.ko," which is a kernel module. To load it into the kernel space, use the insmod tool :
# insmod exploit.ko
O principal problema do bug é a falta de um "spinlock" para sincronização de threads. A solução aqui é:
Primeiro (Alocação Slab/Slub) , alocar um slab/slub específico para cada thread, e nenhuma thread pode controlar ou manipular o tamanho de memória de outra thread.
Segundo (Sincronização) , configurar a Workqueue para evitar interferências e condições de corrida, onde cada thread termina sua tarefa e passa para outra thread em vez de alternar o WB ao mesmo tempo ou usar a função wb_wakeup_delayed.
Terceiro (HLE/RTM) : Ativar HLE/RTM no kernel depende da arquitetura do processador, mas se ele suportar esses dois recursos, por que não usá-los no kernel, por exemplo, na direção do fluxo de um programa ou quando um erro ocorre, tentando reverter para outra exceção em vez de travar "rollback" por meio de instruções como XBEGIN, XABORT, XEN.
MIT