DeepSeek による執筆。
プレーンな IPv4 TCP サーバーが脆弱です。MPTCP はトリガーではありません。
リリース tarball から Linux 6.18.55 をビルドし、通常の IPPROTO_TCP リスナーでカーネルに解放済みメモリを読ませました。KASAN はそれを 2 回報告しました。MPTCP ソケットは一度も作成されておらず、ある実行ではカーネルで MPTCP が無効化されていました。
同じバグにより、カーネルは解放済みオブジェクトからバイトをコピーし、返信パケットに含めて送信します。これは KASLR 破りのために必要なプリミティブであり、未公開の作業でそれが発生するのを観測しています。私たちはカーネルアドレスのリークを構築しておらず、書き込みも証明していません。
ここでコードとログによって証明されているのは、use-after-free が実在し、標準の TCP で到達可能であり、アップストリームの修正がそれを止めるということです。
| カーネル | MPTCP | 試行回数 | 時間 | 結果 |
|---|---|---|---|---|
| 6.18.55、修正なし | 未使用 | 134,955 | 34 秒 | KASAN use-after-free |
| 6.18.55、修正なし | 無効化 | 191,431 | 80 秒 | KASAN use-after-free |
| 6.18.55 + 修正 | 未使用 | 439,316 | 411 秒 | クリーン |
非常に高いです。KASAN ではリーダーが遅いため、バグは数十万回の試行で現れます。通常のカーネルでははるかに稀で、約 4,800 万回の試行で 2 回のイベントを観測し、いずれも同じ 5 秒以内に発生しました。
これはレートを述べるには少なすぎます。私たちが主張できる最大限は、試行あたりおよそ 1e-7 という上限であり、それすら最良ケースです。なぜなら私たちのハーネスは 2 つのパケットを 2 つの CPU に強制的に割り当てますが、実際の NIC は通常 1 つのフローを 1 つの CPU に送るからです。
したがって、クリーンな実行は安全なカーネルを意味しません。数値を引用する前に ANALYSIS.md のセクション 5.2 と 6 を読んでください。
TCP サーバーが SYN を受け取ります。SYN は IPv4 オプション（Record Route または Timestamp）を運びます。カーネルはそれらのオプションをリクエストソケットに保存します。
同じ接続に対する 2 つ目の SYN が到着します。カーネルはそれに対する SYNACK を構築し、保存されたオプションを読み取ります。
同時にハンドシェイクが完了します。子ソケットはコピーではなく同じポインタを取得します。サーバーが子を閉じると、カーネルはプレーンな kfree() でオプションを解放します。
SYNACK のコードはまだそのメモリを読み取っています。これが use-after-free です。同じ読み取りが、解放済みのバイトをパケットに含める原因でもあります。
これはバグトリガーであり、エクスプロイトではありません。カーネルアドレスをリークせず、カーネルメモリに書き込まず、root を取得しません。カーネルが解放済みメモリを読み取ることを示しており、KASAN が判定者です。
リポジトリは意図的にそこで止まっています。以降の段階は非公開で作業され、ここでは公開されていません。
scripts/get-kernel.sh # fetch 6.18.55, sha256 checked, into linux/
scripts/build-kernel.sh vuln # KASAN kernel, no fix
scripts/build-kernel.sh patched # KASAN kernel, with the fix
scripts/build-harness.sh # builds harness/init + initramfs
scripts/run.sh vuln 90 selftest # checks the wiring only
scripts/run.sh vuln 600 # expect a KASAN report
scripts/run.sh patched 600 # expect nothing
gcc、make、bison、flex、bc および qemu-system-x86_64 が必要です。KVM があると大幅に高速化されます。
VM は 2 GB の RAM と 8 個の vCPU を使用します。
1 回の実行では何も表示されないことがあります。 これは安全なカーネルの証拠にはなりません。複数回実行し、ANALYSIS.md に記載されている注意事項をお読みください。
バージョン文字列を信用しないでください。バイナリ内のコードを確認してください。
scripts/check-free-sites.py
実行中のカーネル内にある2つの解放サイトを特定し、それぞれがどの関数を呼び出しているかを示します。kfree（脆弱）または kvfree_call_rcu（修正済み）です。
これが書かれたマシン（6.18.59_1）では、両方のサイトが kvfree_call_rcu を使用しているため、そのカーネルは修正済みです。
以下の3つすべてが当てはまる場合、ホストは影響を受けます。
攻撃者が制御できるのはポイント2です。そのため、ほとんどのインターネットサーバーが影響を受け、「MPTCP を使っていない」ことは助けになりません。
2つの注意点：
accept_source_route=0 はあなたを保護しません。これはソースルーティングのみをブロックし、Record Route や Timestamp はブロックしません。| パス | 内容 |
|---|---|
ANALYSIS.md | 完全なレポート：ソースパス、手法、結果、限界 |
harness/ | QEMU 内で /init として実行されるバグトリガー |
patches/ | アップストリームの修正。対照ビルドに使用 |
scripts/ | 取得、ビルド、実行、チェック用のヘルパー |
evidence/ | KASAN レポート、実行ログ、ビルド比較 |
テスト用カーネルのみ、かつあなたが所有するものに限ります。ここにあるものを、あなたが管理していないシステムに向けるべきではありません。
私たちのコードとテキストは MIT です。patches/ には Linux カーネルのコミットが含まれており、GPL-2.0 のままです。LICENSE を参照してください。