bytereaper77/cve-2025-39866Preuve de concept pour CVE-2025-39866 (UAF et condition de concurrence)
Auteur : Byte Reaper
Ce POC tente d'exploiter la vulnérabilité CVE-2025-39866, qui est une faille dans les systèmes Linux < 6.12.16 due à l'absence de spinlock pour les threads, provoquant une condition de course. Le premier thread tente d'utiliser la structure wb pendant que le thread 2 libère cette structure, ce qui oblige le premier thread à manipuler un pointeur libéré, entraînant un kernel panic pour le système. Nous pouvons diviser l'idée d'exploitation de la vulnérabilité en étapes suivantes :
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
Le principal problème du bug est l'absence de "spinlock" pour la synchronisation des threads. La solution est la suivante :
Premièrement (allocation Slab/Slub), allouer un slab/slub spécifique pour chaque thread, et aucun thread ne peut contrôler ou manipuler la taille mémoire d'un autre thread.
Deuxièmement (synchronisation), configurer la Workqueue pour éviter les interférences et les conditions de course, où chaque thread termine sa tâche puis passe à un autre thread au lieu de changer de WB en même temps ou d'utiliser la fonction wb_wakeup_delayed.
Troisièmement (HLE/RTM) : l'activation de HLE/RTM dans le noyau dépend de l'architecture du processeur, mais si celui-ci prend en charge ces deux fonctions, pourquoi ne pas les utiliser dans le noyau, par exemple, pour diriger le flux d'un programme ou, lorsqu'une erreur se produit, tenter de revenir à une autre exception au lieu de planter "rollback" via des instructions comme XBEGIN, XABORT, XEN.
MIT