CVE-2025-39866 - use-after-free

Autor: Byte Reaper

Beschreibung

Dieser POC versucht, die Schwachstelle CVE-2025-39866 auszunutzen. Dabei handelt es sich um einen Fehler in Linux-Systemen < 6.12.16, der durch das Fehlen eines Spinlocks für Threads eine Race Condition verursacht. Der erste Thread versucht, die wb-Struktur zu verwenden, während Thread 2 diese Struktur freigibt. Dadurch arbeitet der erste Thread mit einem freien Zeiger, was zu einem Kernel-Panic des Systems führt. Wir können den Ansatz zur Ausnutzung der Schwachstelle in die folgenden Phasen unterteilen:

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)

Voraussetzungen :

Linux x86_64
kernel linux  < 6.12.16

Build :

	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

Ausführen :

	# 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

Referenzen :

Beobachtung :

Bald werde ich einen Exploit entwickeln, der andere Methoden zur Manipulation der wb-Struktur verwendet, etwa das Reduzieren des Refcounts oder das Entfernen des wb-Caches aus dem List-Cache. Ich werde außerdem Versuche hinzufügen, Memory Spraying durchzuführen sowie Leaks zu erkennen oder Privilegien im System zu erweitern. Dies ist nur ein Proof of Concept für die Schwachstelle.

Lösung des Problems

Das Hauptproblem des Bugs ist das Fehlen eines „Spinlock“ für die Thread-Synchronisation. Die Lösung hierfür ist:

Erstens (Slab/Slub-Allokation): Weisen Sie jedem Thread einen spezifischen Slab/Slub zu, und kein Thread kann die Speichergröße eines anderen Threads kontrollieren oder manipulieren.

Zweitens (Synchronisation): Konfigurieren Sie die Workqueue so, dass Interferenzen und Race Conditions vermieden werden, wobei jeder Thread seine Aufgabe beendet und zu einem anderen Thread übergeht, anstatt gleichzeitig den WB zu wechseln oder die Funktion wb_wakeup_delayed zu verwenden.

Drittens (HLE/RTM): Die Aktivierung von HLE/RTM im Kernel hängt von der Prozessorarchitektur ab. Wenn der Prozessor diese beiden Funktionen unterstützt, warum sollte man sie nicht im Kernel verwenden? Zum Beispiel, um den Programmfluss zu steuern oder bei einem Fehler zu versuchen, auf eine andere Ausnahme zurückzugreifen, anstatt abzustürzen – ein „Rollback“ mittels Anweisungen wie XBEGIN, XABORT, XEN.

Lizenz :

MIT

CVE-2025-39866

Beliebteste