LinuxカーネルのTCPの脆弱性、Go 1.24以降のサーバーは既定で当たりうる

社内のLinuxで動くGo製のツールが、この脆弱性の条件にそのまま当たっているかもしれません。Linuxカーネルの脆弱性CVE-2026-98432は、Multipath TCP（MPTCP）で待ち受けるサーバーに、認証なしで遠隔からrootの権限でコマンドを実行される恐れがあるものです。そしてgo.modのgoの行が1.24以降のGoのプログラムは、Linuxで待ち受けるとき、既定でMPTCPを使います。

10月30日の時点で、UbuntuとRHELは修正版のカーネルをまだ出していません。先に、自社のサーバーが条件に当たるかを確かめておく段階です。

IPv4のTCPの接続の処理で、解放後使用

CVE-2026-98432は、10月15日にLinuxカーネルのCVEの担当（CNA）が公表しました。IPv4のTCPの接続を確立する処理で、IPオプションのデータを、別の処理がまだ使っているのに解放してしまう不具合です。再送されたSYNを別のCPUが同時に処理する場面と、待ち受けのソケットの間で接続の要求を移す設定（tcp_migrate_req）の場面の2つが書かれています。修正は上流のカーネルに入り、保守中の安定版の各系にも戻されています。

この不具合から攻撃のコードまでを示したのは、Anthropicです。10月27日の研究の公表で、社内の未公開のモデルが、MPTCPで待ち受けるLinuxのサーバーに、資格情報なしでrootの権限でコマンドを実行させるコードを書いたとしました。試作では、カーネルのアドレスを漏らすまでに48分、コマンドの実行まで、さらに5分かかったといいます。AIが攻撃のコードを書いたという側面は、TECHNOVAのAIがChromeやAndroidの防御を破る攻撃を作成Anthropic公表、修正済みが扱っています。

9.8と8.1、評価が割れた理由

深刻度の数字は、出す所によって分かれました。

違いは、ほぼ攻撃の難しさの1項目だけです。編集部は、ディストリビューションの側が、同時に走る処理の競り合いに勝つ必要がある点を、難しさとして数えたとみています。

ただ、編集部は8.1を「急がなくてよい」の意味には読みません。Anthropicの説明では、競り合いに負けても接続の確立が失敗するだけで、システムは落ちません。攻撃する側は、成功するまで何度でも試せます。50分ほど試し続ければ届く、というのが試作の数字でした。

逆に言えば、守る側にも手がかりがあります。同じ相手からの接続の試みが長い時間続く形になるはずなので、通信の記録や侵入の検知で見える余地があると編集部は考えます。とはいえ、見えるかどうかは自社の記録しだいで、更新の代わりにはなりません。

MPTCPの待ち受けは、思ったより身近

MPTCPは、1つの接続で複数の経路を束ねて使う仕組みです。名前だけ聞くと、特別な設定をしたサーバーの話に思えるかもしれません。

ところが、Goは1.24から、Linuxで待ち受けるソケットに既定でMPTCPを使います。GODEBUGのmultipathtcpの既定値が「2」になったためです。この既定は、作ったときのGoのツールチェーンの版を、mainモジュールのgo.modにあるgoの行の版に合わせて決まります。goの行が1.24以降なら、MPTCPで待ち受ける側です。カーネルの側も、MPTCPのソケットを作れるかを決めるnet.mptcp.enabledの初期値は1（有効）です。条件に当たるGoのサーバーを、初期のままのカーネルで動かせば、それだけでMPTCPの待ち受けになります。

Goのセキュリティチームは10月29日、この点を利用者に知らせました。プログラムごとにMPTCPを切る方法（GODEBUG=multipathtcp=0など）も示しましたが、1つでも切り忘れれば残ると注意し、修正版のカーネルへの更新を強く勧めています。さらに、元の不具合はMPTCPに限らず、MPTCPの待ち受けが無いシステムでも、似た攻撃を受ける可能性があるとしています。

編集部は、ここがこの件のいちばんの見落としどころだとみています。監視のエージェントやエクスポーター、リバースプロキシ、社内で作ったAPIのサーバーなど、Goで書かれたものは少なくありません。製品として入れたものは、中でGoの何版を使っているかを、情シスがふだん気にしていないことがほとんどです。

修正の状況（10月30日11時30分の確認）

Red Hatは、使いやすさや安定性などの社内の基準を満たす緩和策は、いまは無いとしています。MPTCPを止める手が使えないという意味ではなく、Red Hatとして勧められる手が無いという言い方です。Amazon Linuxの告知のサイトは、当方から確かめられませんでした。

今週KEVに載ったFragnesiaや、10月17日に取り上げたDirtyCloneと比べると、守り方の向きが違います。この2件は、サーバーの中に入った攻撃者がrootを取るためのものでした。今回は、外からの接続そのものが入口になります。外から届くポートで何が待ち受けているかが、急ぎ度を決めます。

影響する構成と、今週の急ぎ度

MPTCPを止めるのは、あくまで時間稼ぎです。Goのチームが書くとおり、元の不具合はMPTCPに限りません。待ち受けが無いサーバーも、更新の予定からは外さないでください。

今週のうちに確かめる手順

1. 外からつながるLinuxのサーバーでss -M -lを実行し、MPTCPで待ち受けているソケットがあるかを見ます。あわせてsysctl net.mptcp.enabledの値も控えます。
2. 待ち受けていたら、そのプロセスが何かを確かめます。Goで作られていれば、go version -m <実行ファイル>で、作ったときのツールチェーンの版と、埋め込まれた設定（DefaultGODEBUG）が見られます。ここにmultipathtcp=0があればMPTCPを切って作ってあります。Goの開発環境がある端末に実行ファイルの写しを置けば、そこで調べられます。ただ、いちばん確かなのは、手順1のss -M -lで実際の待ち受けを見ることです。
3. UbuntuとRHELのサーバーで、修正版がまだのものは、MPTCPを使う理由が無いかを担当者に確かめたうえで、net.mptcp.enabledを0にし、待ち受けているサービスを再起動します。設定を変えたことは、修正版を当てたあとに戻すかどうかを決めるため、台帳に書いておきます。
4. コンテナで動かしている場合は、使うのは土台のサーバーのカーネルです。コンテナのイメージを作り直しても直らないので、Kubernetesなどのノードのカーネルを更新の対象に入れます。
5. Ubuntu・Red Hatの追跡のページを見て、修正版のカーネルが出たら、再起動の時間を決めて上げます。再起動まで終えたら、uname -rで新しい版で動いているかを確かめます。

Linuxカーネルのほかの脆弱性の確かめ方は、Red HatのLinuxカーネルに複数の脆弱性、対象製品の確認をにもまとめています。