Linux TCP脆弱性、CVSSが9.8に引き上げ

Red Hatは11月2日、Linuxカーネルの脆弱性CVE-2026-98432のCVSSスコアを9.8に引き上げた。それまでは5.9から8.1まで幅のある評価をつけていた。同社は11月1日にRHEL 8、9、10向けの修正済みカーネルを公開している。Ubuntuの状況は依然として「修正作業中」だ。

この脆弱性はIPv4 TCPの接続確立処理にあり、ネットワーク側から認証もユーザー操作も不要でトリガーできる。影響範囲はLinux 4.4以降で、原因は2015年のコミットにまでさかのぼる。

2行の修正で直る競合状態

SYNパケットにIPv4オプション(Record RouteやTimestampなど)が付いていると、カーネルはそれをリクエストソケット上に保存する。ハンドシェイクが完了すると、このメモリへのポインタはコピーされずにそのまま子ソケットへ渡され、双方が同じ領域を共有する。

このとき、別のCPUが再送されたSYNに対してSYN-ACKを組み立てている最中に、子ソケットがちょうど破棄されると、オプション用メモリはkfree()で即座に解放される。SYN-ACKを組み立てる経路は、すでに解放されたメモリを読むことになる。

修正はEric Dumazet氏が提出したもので、コミットはe3f33b0a1d89。kfree()をkfree_rcu()に置き換え、RCUの猶予期間が過ぎてから解放するようにした。変更は2行だけだ。報告者はAnthropicのXinyang Ge氏。CVEレコードは10月15日に公開された。安定版ブランチの修正バージョンは5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10で、メインラインは7.3で修正された。

Anthropicの主張を裏付けられるのはAnthropicだけ

この脆弱性が注目を集めたのは、10月27日にAnthropicのFrontier Red Teamが公開した記事がきっかけだ。記事によると、未公開の社内モデルがエクスプロイトを作成し、MPTCPのリッスンを有効にしたサーバー上で、認証なしのリモート攻撃者がrootとしてコマンドを実行できるという。

攻略は2段階で進む。まず競合状態を利用してカーネルメモリを境界外から読み出し、ポインタを漏洩させてKASLRを回避する。次に境界外書き込みでコールバック関数ポインタを上書きする。Anthropicが示した所要時間は、ポインタの漏洩に約48分、そこからコマンド実行まで約5分だ。

ここは切り分けて見る必要がある。エクスプロイトコード、テストに使ったカーネルバージョンと設定はいずれも公開されておらず、第三者による検証もない。CVEレコードにも修正コミットにもMPTCPへの言及はなく、記事もなぜMPTCPが必須なのかを説明していない。53分という数字は未知の環境での値であり、本番サーバーにそのまま当てはめることはできない。11月2日時点で、ベンダー、CERT、カーネルCVEチームのいずれも実環境での悪用を報告しておらず、CISAの既知の悪用された脆弱性カタログにも掲載されていない。

中国語圏の一部の報道では「Anthropicがエクスプロイトの例を公開した」と書かれているが、正確には攻略手順の説明を公開したのであって、実行可能なコードは出していない。

スコアをめぐる見解の相違も続いている。カーネルCVEチームとRed Hatは現在9.8をつけ、Oracle、SUSE、Amazonは8.1としている。差は攻撃の複雑さを低と見るか高と見るかにある。NVDはまだ独自のスコアを出していない。

Goが前提条件をデフォルトにした

10月29日のGoセキュリティチームの告知で、影響範囲は広がった。Go 1.24以降、multipathtcpのデフォルト値は2で、待ち受け側だけでMPTCPを有効にする設定だ。つまり、net.Listenでサービスを起動するGoプログラムは、デフォルトのままでAnthropicが実演した前提条件を満たす。

Goチームが示した緩和策は、実行時にGODEBUG=multipathtcp=0を設定するか、メインモジュールのgo.modにgodebug multipathtcp=0と書くことだ。同時に、プログラムごとに無効化するこの方法を「a fragile mitigation(脆弱な緩和策)」と呼んでいる。Goチームは、現時点でデフォルト値を変えるのは時期尚早としている。カーネル側ではnet.mptcp.enabledを0にできるが、これで取り除けるのは実演された前提条件だけで、脆弱性そのものは残る。

運用担当者がまずできること

ディストリビューション別の状況(10月29日確認分と11月2日確認分が混在)は、おおよそ次のとおり。

クラウドホストの利用者にはUbuntuの比率が低くないため、この表で最も注意すべきはUbuntuだ。多くのディストリビューションはバックポートで修正するため、修正済みかどうかは各社のセキュリティ公告にあるパッケージバージョンと照合して判断する必要がある。uname -rのメジャーバージョンだけを見ると誤判定しやすい。新しいカーネルは再起動して初めて有効になり、ライブパッチは別の仕組みなので個別に確認が要る。

パッチをまだ入手できないマシンでは、まずどのサービスがMPTCPで待ち受けているかを洗い出す。特にGo 1.24以降でビルドしたバイナリが対象だ。そのうえで、上記の方法で無効化するかを判断する。MPTCPを無効にすればリスクがすべて消えるとはベンダーも確認しておらず、この手順は時間稼ぎにすぎない。カーネルのクラッシュログにip_options_buildのような関数名が出ている場合も調べておきたい。

参考資料:Anthropic Frontier Red Teamの記事の公開されている紹介、Rescanaの脆弱性情報、CocoLoop、Goセキュリティチームの告知、DebianおよびRed Hatのセキュリティトラッカー。スコアとディストリビューションごとの修正状況は各ベンダーの公表値に従う。Anthropicのエクスプロイトの詳細は独立した検証を受けていない。