bytereaper77/cve-2025-39866Prova di concetto per CVE-2025-39866 (use-after-free e race condition)
Autore: Byte Reaper
Questo POC tenta di sfruttare la vulnerabilità CVE-2025-39866, un difetto nei sistemi Linux < 6.12.16 dovuto alla mancanza di uno spinlock per i thread, che causa una race condition. Il primo thread cerca di usare la struct wb mentre il thread 2 libera questa struttura, facendo sì che il primo thread abbia a che fare con un puntatore libero, portando a un kernel panic del sistema. Possiamo dividere l'idea di sfruttare la vulnerabilità nelle seguenti fasi:
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
Il problema principale del bug è la mancanza di uno "spinlock" per la sincronizzazione dei thread. La soluzione qui è:
Prima (Slab/Slub Allocation) , allocare uno slab/slub specifico per ogni thread, e nessun thread può controllare o manipolare la dimensione della memoria di un altro thread.
In secondo luogo (Synchronization) , configurare la Workqueue per evitare interferenze e race condition, dove ogni thread completa il proprio compito e passa a un altro thread invece di cambiare WB contemporaneamente o usare la funzione wb_wakeup_delayed.
In terzo luogo (HLE/RTM) : attivare HLE/RTM nel kernel dipende dall'architettura del processore, ma se supporta queste due funzionalità, perché non usarle nel kernel, ad esempio, per dirigere il flusso di un programma o quando si verifica un errore, tentando di tornare a un'altra eccezione invece di mandare in crash "rollback" tramite istruzioni come XBEGIN, XABORT, XEN.
MIT