CVE-2025-39866 - use-after-free

Autor: Byte Reaper

Descripción

Este POC intenta explotar la vulnerabilidad CVE-2025-39866, que es una falla en sistemas Linux < 6.12.16 debida a la falta de un spinlock para los hilos, lo que provoca una condición de carrera. El primer hilo intenta usar la estructura wb mientras el hilo 2 libera esta estructura, haciendo que el primer hilo maneje un puntero liberado, lo que provoca un pánico del kernel en el sistema. Podemos dividir la idea de explotar la vulnerabilidad en las siguientes 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)

Requisitos :

Linux x86_64
kernel linux  < 6.12.16

Compilación :

	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

Ejecución :

	# 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 

Referencias :

• NVD : https://nvd.nist.gov/vuln/detail/CVE-2025-39866
• CVE : https://www.cve.org/CVERecord?id=CVE-2025-39866

Observación :

• Pronto desarrollaré un exploit que use otros métodos para manipular la estructura wb, como reducir el refcount o eliminar la caché wb de la caché de lista. También añadiré intentos de ejecutar Memory Spraying e intentos de detectar fugas o escalar privilegios en el sistema. Esto es solo una prueba de concepto de la vulnerabilidad.

Solución del problema

El problema principal del fallo es la falta de un "spinlock" para la sincronización de hilos. La solución aquí es:

Primero (Asignación Slab/Slub) , asigne un slab/slub específico para cada hilo, y ningún hilo puede controlar o manipular el tamaño de memoria de otro hilo.

En segundo lugar (Sincronización) , configure la Workqueue para evitar interferencias y condiciones de carrera, donde cada hilo termina su tarea y pasa a otro hilo en lugar de cambiar WB al mismo tiempo o usar la función wb_wakeup_delayed.

En tercer lugar (HLE/RTM) : Activar HLE/RTM en el kernel depende de la arquitectura del procesador, pero si soporta estas dos características, ¿por qué no usarlas en el kernel, por ejemplo, para dirigir el flujo de un programa o, cuando ocurre un error, intentar revertir a otra excepción en lugar de bloquearse mediante un "rollback" con instrucciones como XBEGIN, XABORT, XEN.

Licencia :

MIT