著者: Byte Reaper
このPoCは、スピンロックがないためにスレッド間で競合状態を引き起こすLinuxシステム<6.12.16の脆弱性CVE-2025-39866を悪用しようとするものです。最初のスレッドがwb構造体を使用しようとする一方で、スレッド2がこの構造体を解放し、その結果、最初のスレッドが解放済みポインタを扱うことになり、システムのカーネルパニックを引き起こします。この脆弱性の悪用の考え方は、以下の段階に分けられます。
ステップ1：スレッド1「メインPID」を作成
- ルートdentryを取得
- ファイルtxt writebackターゲットを作成
- 構造体inodeを作成
- wbオブジェクトを作成
- wbのポインタをwb_oldに保存
ステップ2：
- ワークアイテムをスケジュールするスレッド2（kthread）を作成
- ワークアイテムは「inode_switch_wbs_work_fn」を実行し、「inode->i_wb」を更新し、「wb_put_many」を介して重要な解放をスケジュール
ステップ3：
- スレッド2：wb_olbを解放
- スレッド1 -> ポインタ - wbオブジェクトを解放（古いものを解放）
-> 解放済みアドレスにアクセス -> カーネルクラッシュ（セグフォルト）
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
このバグの主な問題は、スレッド同期のための「スピンロック」がないことです。ここでの解決策は以下の通りです。
第一に（Slab/Slub割り当て）、各スレッドに特定のslab/slubを割り当て、どのスレッドも他のスレッドのメモリサイズを制御または操作できないようにします。
第二に（同期）、Workqueueを構成して干渉や競合状態を回避します。各スレッドはタスクを完了してから別のスレッドに移り、同時にWBを切り替えたりwb_wakeup_delayed関数を使用したりしません。
第三に（HLE/RTM）：カーネルでのHLE/RTMの有効化はプロセッサアーキテクチャに依存しますが、これらの機能をサポートしているのであれば、カーネルで使用しない手はありません。例えば、プログラムの流れを指示する場合や、エラーが発生した場合に、クラッシュする代わりに別の例外に戻ろうとする「ロールバック」をXBEGIN、XABORT、XENなどの命令を介して行うことができます。
MIT