LinuxカーネルのIPv4 TCP処理の脆弱性CVE-2026-98432

脆弱性の内容

CVEチームの告知によると、tcp_v4_syn_recv_sock()は要求ソケットのireq->ireq_optの所有権を、複製せずに子ソケット（newinet->inet_opt）へ移す⁠［1］。別のCPUは、同じ要求ソケットへの再送のSYNを並行して処理し、tcp_check_req()からSYNACKを送りうる⁠［1］。このときtcp_v4_send_synack()などは、rcu_read_lock()だけでireq->ireq_optを読む⁠［1］。

CVEチームは、コミット079096f103fa以降は要求ソケットをリスナーのロックを持たずに処理するため、SYNACKの組み立て中に子ソケットが解放されるのを妨げるものが無いと説明した⁠［1］。TCPの子ソケットはSOCK_RCU_FREEを持たず、inet_sock_destruct()はinet_optを通常のkfree()で解放する⁠［1］。その結果、ip_options_build()でuse-after-freeに至る⁠［1］。

CVEチームの告知では、要求ソケットの移行（net.ipv4.tcp_migrate_req=1か、BPF_SK_REUSEPORT_SELECT_OR_MIGRATEのプログラム）にも同様の問題がある⁠［1］。古い要求ソケットとその複製が同じireq_optを共有し、tcp_v4_reqsk_destructor()も通常のkfree()を使っている⁠［1］。SYNACKのタイマー自体は要求ソケットへの参照を持ち、子の解放より前にinet_csk_reqsk_queue_drop()がtimer_delete_sync()を呼ぶため、問題ではないとした⁠［1］。

CVEチームによると、読み手はすでにRCUを使い、inet_optを置き換えるほかの経路もkfree_rcu()を使っている⁠［1］。修正は、inet_sock_destruct()とtcp_v4_reqsk_destructor()にもkfree_rcu()を使う⁠［1］。IPv6は、tcp_v6_syn_recv_sock()がオプションを複製するため、1つ目の問題の影響を受けない⁠［1］。修正のコミットe3f33b0a1d89のFixesタグには079096f103faとc905dee62232が並び、Reported-byにはAnthropicの報告者が載っている⁠［4］。

CVEレコードのCNAの評価の説明によると、認証されていない相手は、TCPのSYNにIPv4のRecord RouteかTimestampのオプションを入れ、再送したSYNで解放と競合させる⁠［3］。待ち受けるサーバーに対し、相手はオプション付きの要求を繰り返し作り、再送のSYNを同じ接続の確立と切断に競合させられる⁠［3］。競合の両側は攻撃者が引き起こすもので、マルチコアのスケジューリングとヒープの整形は攻撃者の影響の外の条件ではないとした⁠［3］。処理はTCPのハンドシェイクの間、アプリケーションの認証より前にtcp_check_req()へ届き、利用者の操作も要らない⁠［3］。

Red Hatは評価の理由に、認証の無い遠隔の攻撃者が標準のIPv4 TCPの通信で、ローカルの権限も利用者の操作も無しに、カーネルメモリの破壊か即時のクラッシュを起こせることを挙げた⁠［21］。確実な任意コード実行には精密なヒープの制御が要るが、ネットワークの前提が無く深刻な不安定化の可能性があるため、Importantより上にしたと説明した⁠［21］。RHSBでRed Hatは、認証されていない遠隔の攻撃者でもTCP接続要求の処理中の競合状態を突いて遠隔コード実行を起こしうるとし、悪用には要求の精密なタイミングが要ると書いた⁠［23］。

目次へ

時系列

目次へ

対象の製品と版

CVEチームは告知で、問題がLinux 4.4のコミット079096f103faで入ったとし、修正の入った版を8つ挙げた〔注3〕⁠［1］。影響を受けない版はバックポートで変わりうるとして、CVEレコードで最新の状態を確かめるよう求めている⁠［1］。

Red HatはRHSBで、脆弱な版のカーネルでIPv4 TCPを有効にしたすべてのシステムが影響を受け、インバウンドのTCP接続を受けるシステムが最も直接にさらされるとした⁠［23］。RHELのカーネルに依存する製品（RHEL CoreOSを含む）も、影響を受けうる⁠［23］。

AlmaLinuxの告知によると、脆弱なコードはカーネルが接続要求を処理する間、アプリケーションが接続を見る前に動き、待ち受けのIPv4 TCPポートへのIPv4オプション付きのSYNで到達する⁠［29］。要求ソケットの移行の設定（net.ipv4.tcp_migrate_req）は既定で無効である⁠［29］。AlmaLinuxは、告知を書いた段階で修正されたRHELのカーネルは無く、安定版（5.10・5.15・6.12）から上流の修正をサポート中のすべての系列にバックポートしたと説明した⁠［29］。CentOS Stream・RHELより先に出荷することは、技術運営委員会のALESCoが決めた⁠［29］。

MPTCPとの関係

Go Security Teamは、実証された攻撃は標的のシステムにMPTCPのリスナーがあることを要するとしたうえで、根本のバグはMPTCPに固有ではないとした⁠［33］。MPTCPのリスナーの無い系も、類似の攻撃に脆弱でありうる⁠［33］。Go 1.24以降、Goのプログラムは、Linuxのlistenソケットで既定でMPTCPを有効にする⁠［33］。

AlmaLinuxはMPTCPを無効にして出荷しており、管理者が有効にしない限り、アプリケーションはMPTCPのリスナーを開けない⁠［29］。バグは通常のIPv4 TCPのコードにあるので、MPTCPの無い系にも修正が要ると書いた⁠［29］。

CIQの確認と緩和の手順では、net.mptcp.enabled=0を読み戻した状態でも、試したすべてのカーネルで通常のTCPリスナーがRecord Route付きのSYNに応じ、SYN-ACKでオプションを返した⁠［32］。CIQはMPTCPの無効化だけでは足りないとし、CVEの記録（kernel.orgのCNAのmboxとcve.org）にはMPTCPの語が無いとも書いた⁠［32］。The Hacker Newsは、MPTCPとこのバグの結び付きはAnthropicの記事に由来すると報じた⁠［40］。

目次へ

悪用の状況

Anthropicの記事によると、攻撃に認証情報も利用者の操作も要らず、根本の脆弱性はカーネルのネットワークスタックの競合状態によるUAFだ⁠［14］。第1段階は遠隔からKASLRを破る段階で、攻撃者は競合を突いて、自ら制御する長さのフィールドをカーネルに読ませ、余分なバイトを送り返させる⁠［14］。応答にカーネルのポインタが1つでも含まれていれば、攻撃者はカーネルのアドレス配置を知ることができる⁠［14］。

第2段階では、同じUAFでバッファをあふれさせてコールバックのポインタを上書きし、通常のプロトコル機能でカーネルメモリに置いておいたペイロードを呼ばせる⁠［14］。ペイロードは既存のカーネル関数をつなぎ、最後に攻撃者の選んだシェルコマンドをrootで動かす⁠［14］。競合に負けてもハンドシェイクが失敗するだけでシステム全体は落ちないため、攻撃者は成功するまで再試行できる⁠［14］。実証のコードでは、カーネルのポインタの漏えいに48分、シェルコマンドの実行までさらに5分かかる⁠［14］。

Anthropicは記事で、過去数か月に未公開の社内の研究用モデルを使い、ブラウザやOSなど、世界で最も広く使われるソフトウェアの重大な脆弱性を見つけたと説明した⁠［14］。Chrome、Safari、Android、Windows、Linuxの5つの攻撃チェーンの詳細を示し、Linuxの例にこの脆弱性を挙げた⁠［14］。各脆弱性は協調的開示の方針で開発元に報告し、方針は修正まで90日間、その後の45日間は公開の勧告を超える詳細を論じないと定める⁠［14］。この脆弱性は上流で修正され、保守中のすべての安定版ブランチにバックポートされたと書いた⁠［14］。

CloudLinuxは10月29日のステータスページで、引き起こすには既定でない特定の設定が要り、悪用は複雑とみなされるとした⁠［31］。CloudLinuxは10月30日のブログで、カーネルチームがAnthropicの主張を再現できなかったと説明し、実環境での悪用は報告されていないと書いた⁠［30］。

The Hacker Newsは10月29日の記事で、ベンダーの勧告、CVEレコード、Anthropicの記事のどれも、この脆弱性を使った攻撃を報告していないと報じた⁠［40］。

BleepingComputerとCSO Onlineも、この脆弱性の記事を公開した⁠［41、42］。

オランダのNCSCは、CVE-2026-99999とあわせた勧告NCSC-2026-0461で、悪用の複雑さと既知の配布元の追加の対策から、大規模な悪用は起こりにくいとした⁠［38］。カーネルのネットワークスタックの脆弱性は認証前に遠隔から突ける数少ない種類で、注目に値するとも書いた⁠［38］。

目次へ

修正と回避策

CVEチームは最新の安定版カーネルへの更新を推奨し、個別のコミットの取り込みはカーネルのコミュニティとして推奨も支援もしないとした⁠［1］。更新できない場合の個別の修正には、8つのコミットを挙げた⁠［1］。

パケットの遮断による緩和

Red HatはRHSBで、IPオプションを含む受信のIPv4 TCPパケットを捨てるnftablesのテーブル（inputフック、priority -310）を緩和策として示した⁠［23］。このテーブルで暴露は減るが、完全には防げない⁠［23］。通常のTCPオプションはTCPヘッダで運ばれて許可されたままなので、通常のアプリケーションの通信は影響を受けないと見込む⁠［23］。ルールは自分の通信・ネットワーク構成・運用の要件と照らし、本番以外の環境で試してから入れるよう求めた⁠［23］。

Red Hatは、通信の遮断は必要な業務を妨げうるうえ、パッチの代わりにならず、カーネルのセキュリティ更新の適用だけが完全な解決策だとした⁠［23］。CloudLinuxは10月30日22時55分（UTC）に更新したブログで緩和策は無いとし、Red Hatが展開の容易さ・幅広い適用性・安定性の基準を満たす緩和策は無いとしていると書いた⁠［30］。

AlmaLinuxは、IPv4オプション付きのTCPパケットをprerouting（priority -300）で捨てるnftablesのルールを、8・9・10で試した⁠［29］。オプション付きの接続は落ち、通常の接続は動き続けた⁠［29］。ルールは再起動で消え、同じホストのコンテナ間の通信は素通りしうる⁠［29］。CIPSOのセキュリティラベル（NetLabel）に頼るネットワークでは使わないよう求め、IPv6の通信にはルールは要らないとした⁠［29］。

AlmaLinuxの告知によると、MPTCPの無効化（net.mptcp.enabled = 0）は新しいMPTCPソケットの作成を止めるだけで、開いたままのリスナーにはサービスの再起動が要る⁠［29］。どちらの手順も修正ではないとも書いた⁠［29］。CIQは、パケットフィルタを同じネットワークの別のホストからRecord RouteとTimestampのオプションで試した⁠［32］。IPv6、断片化したパケット、ほかの経路は試しておらず、CPUの負荷も測っていない⁠［32］。

Goのプログラムでの緩和

Go Security Teamの告知（oss-security掲載の写し）によると、既定のMPTCPは、実行時には環境変数GODEBUG=multipathtcp=0で無効にできる⁠［33］。ビルド時にはgo.modにgodebug multipathtcp=0を置けば無効になり、SetMultipathTCPなどの呼び出しはこの設定より優先する⁠［33］。Go Security Teamは、プログラムごとのMPTCPの無効化は壊れやすい緩和策だとし、修正済みのカーネルへの更新を強く推奨した⁠［33］。この段階でGoの既定の動作を変えることは時期尚早だとし、議論はgo.dev/issue/82717で続けるとした⁠［33］。

クラウド事業者と利用組織

Amazon Web Servicesは速報2026-160-AWSで、Amazon Linux 2と2023のカーネル（kernel-4.14・5.4・5.10・5.15・6.1・6.12・6.18）の修正パッケージを提供済みとした⁠［28］。利用者には更新と再起動を求め、EC2で自ら管理するLinuxインスタンスのカーネルの更新は利用者の責任とした⁠［28］。

• Amazon EKSは最適化したAmazon Linux 2023のAMI（v20261031）を出し、Auto ModeのAMIは11月1日までに全世界へ配り終える見込みとした⁠［28］。
• Fargateでは、11月1日6時（PDT）以降に起動したタスクが修正済みのプラットフォームの版を使う⁠［28］。
• Bottlerocketの更新AMIは、11月2日から提供する見込みとした⁠［28］。
• Lambdaは公開のIPv4 TCPポートを持たず影響を受けないが、多層防御としてサービス基盤にカーネルのパッチを当てている⁠［28］。

CloudLinuxは、共有ホスティングのサーバーはウェブ・メール・SSH用にIPv4 TCPのポートを開けており、影響を受けるサーバーではそれらのポートから脆弱なコードに届くと説明した⁠［30］。ホスティング事業者のSiteGround Hostingも、この脆弱性のブログ記事を公開した⁠［35］。

カーリルは10月30日の発表で、各サービス（カーリル、Unitrad API、「カーリル for AI」、学校図書館支援プログラムなど）をLinuxサーバーで運用していると説明した⁠［34］。そのサーバーには、影響を受けるものが含まれる⁠［34］。配布元から修正版カーネルが出ているサーバーには、修正版を適用して再起動を終えた⁠［34］。修正版の無いディストリビューションのサーバーには、「IPオプション付きのTCPパケット」をファイアウォールで遮断する緩和策を10月30日に適用した⁠［34］。

カーリルの発表によると、これまでの作業に伴うサービスの停止は起きておらず、利用者と図書館の対応も要らない⁠［34］。10月30日の段階で、自社のサービスに不正アクセスや情報漏えいなどの被害は確認されていないとした⁠［34］。修正版の適用に伴い、各サービスが「停止したり不安定になる可能性」があるとも書いた⁠［34］。

目次へ

未公表の事項

• Anthropicが脆弱性をカーネルの開発者に報告した日
• Anthropicが実証に使った攻撃コードと、試したカーネルの版と構成（CloudLinuxは攻撃コードは公開されていないとした⁠［30］）
• MPTCPのリスナーの無いサーバーへの同じ方法の攻撃の成否
• UbuntuとRHELの修正版、AlmaLinuxの本番リポジトリ向けの修正版の提供時期（Red Hatは修正の公開を急いでいるとした⁠［23］）
• tcp_v6_reqsk_destructor()にある同じ移行の問題への修正（CVEチームは別のパッチで対処するとした⁠［1］）

注

• 〔注1〕The Hacker Newsによると、Red HatのCVEページは10月29日にModerate・5.9、VEXはImportant・8.1だった⁠［40］。
• 〔注2〕The Hacker Newsは10月29日の記事の表で、Amazon Linux 2023のkernel6.18の評価をImportant・7.0と載せた⁠［40］。
• 〔注3〕マイナビニュースTECH+は10月30日の記事で、CVEチームによると6.12.113、6.18.56、7.2.10、7.3-rc7で修正されていると報じた⁠［43］。

出典

更新記録

• 2026年11月1日：公開した。
• 2026年11月2日：「脆弱性の内容」の修正コミットの報告者の名前を、所属と役割の表記に改めた。

目次へ

関連記事

同じ当事者の資料を引く記事

• AnthropicのAIモデルによる米政府機関などのサイトでの意図しない行動（anthropic.com）

  判明 2026年10月9日 公開 2026年10月25日 AI関連、行政、国外

• AnthropicによるIoT機器でのAIモデルの自己複製の評価（anthropic.com）

  判明 2026年10月12日 公開 2026年10月17日 AI関連、国外