Linux TCP Use-After-Free：パッチ適用かミティゲーションか

カーネルのTCPハンドシェイク経路に、リモートから到達可能な解放後使用（use-after-free）があり、ディストリビューションはまだ修正を出していません。しかも、認証なしでrootを取得できる動作するエクスプロイトがすでに実証されています。さて、どうしますか。じっと待つか、それともファイアウォールでパケットを落とし始めるか。CVE-2026-98432として開示されたLinux TCP use-after-freeは、セキュリティ運用で最も古典的な判断、つまりパッチ適用かミティゲーションかを考えるための良い事例です。正直に言えば、この二つは対等ではありません。片方だけが実際に問題を解決します。

私は両方の立場でこの判断を下してきました。紙の上では緩和策で十分に見えたので、緊急のカーネル展開を見送ったこともあれば、「一時的な」ファイアウォール規則が、それが隠していたCVEのことを誰もが忘れたまま、8か月も本番環境で静かに腐っていくのを見たこともあります。このバグは、どのアプローチがいつ勝つのかを話し合うのに良いきっかけです。ここではトレードオフが異例なほど明快だからです。

TCP Use-After-Freeの実態

仕組みが重要なのは、それによってミティゲーションにできること・できないことが決まるからです。サーバーがIPv4のTCP接続を受け付けると、カーネルはハンドシェイク途中の状態を軽量なリクエストソケットで管理し、ハンドシェイクが完了すると完全なソケットに昇格させます。接続元のIPv4ヘッダにオプションが含まれていた場合、カーネルはそれを保存しておき、応答時にエコーバックします。バグはここにあります。カーネルは保存されたオプションをコピーせずに新しい接続へ渡し、そのうえで即座に解放してしまいます。一方、別のCPUはまさにそのオプションを読み取ってハンドシェイクの応答を組み立てているかもしれません。これがuse-after-freeであり、アプリケーションコードが1行も動く前に、リモートの未認証の相手から到達できてしまいます。

上流の修正はEric Dumazetによるもので、4行で済みます。2つの単純なkfree()呼び出しをkfree_rcu()に置き換えるだけです。これにより、すべての読み取り側がメモリの使用を終えるまで解放が遅延されます。RCUの下で読み取る側は、こちらから見えない参照を保持しているので、グレースピリオドが過ぎるまで待ってから回収します。この種のバグに対する典型的なカーネルの修正です。カーネルのCNAはCVSS 9.8と採点しました。Red Hatは当初8.1としていましたが、10月30日にネットワーク前提条件がないことを理由に9.8（Critical）へ引き上げました。

露出度の計算を変える点が2つあります。第一に、競合状態は穏当に負けます。失敗した試行はカーネルパニックを起こさず、単にハンドシェイクが失敗するだけなので、攻撃者は何度でも再試行できます。第二に、Anthropicが実証したエクスプロイト経路は、マルチパスTCPのリスナーを持つホストを狙うものです。Goセキュリティチームによれば、Go 1.24以降、Goプログラムはカーネルが許す限りLinux上でデフォルトでMPTCPリスナーを開いています。自分のフリートを確認しましょう。

ss -Mlnp                 # MPTCP listeners and their owning processes
sysctl net.mptcp.enabled # 1 means apps may open MPTCP sockets

ss -Mの出力が空なら、MPTCPリスナーはありません。ただし安心しすぎないことです。Goチームは、根本的なバグはMPTCP固有のものではないと明言しています。これはハンドシェイク処理に潜む汎用的なUAFであり、MPTCPは単に誰かがエンドツーエンドで実証した経路にすぎません。

パッチの経路：修正済みカーネル、再起動、完了

パッチ適用は説明するのが退屈です。脆弱性を形だけ変えるのではなく、実際に消せる唯一の選択肢だからです。修正済みカーネルは10月11日と15日に、保守対象のすべての安定版系列に上流から提供されました。このバグはLinux 4.4までさかのぼるため、上流がもはや対応しないような古いカーネルを含め、多くの長期運用システムが影響を受けています。

問題は再起動です。カーネルのアップデートは、マシンが新しいカーネルで起動するまで何の効果もありません。そして再起動にこそ本当の運用コストがあります。ドレインされたKubernetesノード、フェイルオーバーの予行演習、業務時間中には誰も再起動したがらないデータベースのプライマリ。だから「とにかくパッチを当てろ」は常に正しいものの、助言としては十分ではありません。ロールアウト計画が必要です。まずカナリアホスト、次にステートレスな層、最後にメンテナンスウィンドウを設けたステートフルな層。全社的な緊急カーネル入れ替えを経験したことがあるなら、この手順はよく知っているはずです。これをうまくこなすチームは、何も燃えていないときにノードのドレインを練習しているチームです。平穏な火曜日に培う防御的エンジニアリングの習慣が、9.8の脆弱性が来たときに効いてきます。

見落としやすい罠を一つ挙げておきます。dpkg -lやrpm -q kernelで修正済みパッケージが表示されても、実行中のカーネルがそれより古ければ意味がありません。実際に動いているものはuname -rで確認します。RHEL系なら、needs-restarting -rで再起動が保留中かどうかを端的に確認できます。インシデント後のレポートで、「パッチ適用済み」のフリートが、実はインストールされただけで実行されていないカーネルの集まりだったケースを何度も見てきました。実行中のバージョンは上流の番号ではなく、ディストリビューションのトラッカーと照合してください。ディストリのカーネルは独自のバージョン体系の下でバックポートを含んでいるからです。

ミティゲーションの経路：IPv4オプションを落とし、MPTCPを無効化

公開されている暫定的なミティゲーションは、脆弱な経路のトリガー条件であるIPオプション付きの受信IPv4 TCPパケットを落とすnftablesの規則です。使っていなければ、MPTCPを無効化（sysctl -w net.mptcp.enabled=0）して補完できます。どちらも高速で、再起動は不要、構成管理を使えば半日で展開できます。それが魅力です。

ここで熱意を少し冷ましておく必要があります。Red Hatの公式アドバイザリは、この規則が「この脆弱性の露出を減らすが、完全に防ぐことはできない」と述べています。この一文は二度読んでください。ミティゲーションは攻撃面を狭めますが、閉じるわけではありません。IPオプション付きのパケットは通常のトラフィックではまれで、多くのミドルボックスがいずれにせよ落とすため、インターネット越しの悪用は起こりにくいと考えられています。しかし「まれ」と「不可能」は別の言葉です。そしてバグは、誰かがたまたまテストしたオプション経路だけにあるのではなく、汎用のハンドシェイクコードにあります。

もう一つ、より見えにくいコストがあります。ミティゲーションは偽りの安心感を生みます。チケットは「ほぼ完了」に移され、パッチ作業から緊急性が抜け落ち、6週間後には、なぜそうしたのかの記憶も薄れたまま、脆弱なカーネルをパケットフィルタの裏で動かし続けることになります。このパターンについては、PHPの重大なCVEの対応期間を扱った際にも書いたことがあります。脆弱なものを即座にオフラインにしたチームのほうが、巧妙なフィルタを積み重ねたチームより良い結果を出していました。教訓は同じで、スタックが違うだけです。

パッチかミティゲーションか：どちらが勝つのか

プレッシャーの中でこの判断を何年も下してきた経験から、正直な採点表を示します。

• お使いのディストリビューションで修正済みカーネルが提供されている。パッチ適用の圧勝です。Debian、SUSE Enterprise、Oracle UEK、Amazon Linuxはいずれも修正を出しています。4行の上流修正より賢いミティゲーションは存在しません。再起動をスケジュールし、リング状に展開して次へ進みましょう。
• 修正済みカーネルはまだないが、露出は現実的。すぐにミティゲーションを行います。まさにそのためのものです。UbuntuとRHELは10月末時点でもまだ「Vulnerable」／「affected」でした。インターネットに公開されていてMPTCPリスナーがあるなら、今日中にIPオプション付きパケットを落とし、MPTCPを無効化しましょう。同時に、修正済みカーネルはリリースと同じようにブロッカーとして追跡してください。
• インターネットに面しているが、マネージドなフロントドアの背後にある。緊急度は下がります。AWSの案内、つまりロードバランサー、CloudFront、API Gatewayを経由するトラフィックが、信頼できない生のTCPとしてインスタンスに届くことはない、という説明は妥当です。それでもミティゲーションは行います（安上がりだからです）。パッチは緊急対応ではなく通常のサイクルで当てます。
• シングルコアまたはシングルキューのシステム。優先度は低めです。競合状態を起こすには、複数CPUでの並行パケット処理が必要だからです。組み込み機器や小さなVMには余裕があります。ただし、誰も再起動しないマシンになりがちでもあるので、「優先度低」が「永久に放置」にならないよう注意してください。
• サポート終了のカーネル（上流で5.10より前）。上流に依存しない唯一の選択肢がミティゲーションです。これは本当にミティゲーションが勝つケースです。代替は、来ないかもしれないベンダーのバックポートだからです。同時に、そのマシン自体が脆弱性であるという強いシグナルでもあり、本当の解決策はそれを入れ替えることです。

本当の問題はディストリビューションの遅れ

気になるべきは、バグそのものではありません。4行のUAF修正は、安定版カーネルに毎月入ってきます。問題は、地球上で最も大きいサーバー向けディストリビューションの2つ、UbuntuとRHELが、上流から2週間以上経っても修正を出していなかったことです。一方でAmazon Linuxは、すべてのカーネルにパッチを当て、コミュニティ版の再構築であるAlmaLinuxは、上流より先にテスト版で修正済みカーネルを用意していました。HNのコメント欄も気づき、腹を立てるのももっともです。これらはサーバーへの適合性を最も強く売りにしているディストリビューションなのですから。

実務者にとっての教訓は地味です。露出の期間を決めるのは上流ではなく、ベンダーのバックポートの仕組みです。これは二つのことを示しています。第一に、ディストリのトラッカーのURLを把握し、実際に監視することです。このCVEはNVDで「Received」のまま分析がなく、一方でカーネルCNA、Red Hat、各ディストリはすでに詳細なページを公開していました。第二に、ディストリの対応速度を選定基準にすることです。Amazon Linuxは、既存の2大ディストリより明らかに速いカーネル修正のパイプラインを示しました。これはマーケティング資料では目立ちませんが、9.8の脆弱性が出る10月31日の週末には大きな差になります。

AIが書いたエクスプロイトが時計を早める

開示の中で最も重要な一文は、読み飛ばしやすいものです。Anthropicは、自社のClaudeモデルが、初期のプロンプト入力のあとで、カーネルポインタの漏洩からrootシェルまでを機械時間1時間未満で、動作するリモートroot エクスプロイトに仕上げたと報告しています。同社はそれを公開していませんし、HNの懐疑派は「信じてくれ」という語り口を大いにからかいました。もっともな反応です。それでも、マーケティングとして割り引いたとしても、方向性は明らかです。「差分が安定版ツリーに入る」から「動作するエクスプロイトが存在する」までの時間は縮まりつつあります。エクスプロイト作成のボトルネックは、そもそもバグではなく、差分を読んでヒープグルーミングをできる人間だったからです。

これはパッチかミティゲーションかの判断の時間枠を縮めます。エクスプロイトの開発に数週間かかっていた時代には、「今はミティゲーション、パッチは次のメンテナンスウィンドウで」は擁護できました。公開コミットからモデルが一晩でPoCを量産できるなら、ミティゲーションの段階は数時間単位で測り、パッチの段階は数日単位で測る必要があります。4行の修正は公開されています。誰でも研究できます。エクスプロイトも同じくらい出回っていると想定すべきです。

私の推奨

パッチを当てること。ミティゲーションは橋渡しとしてのみ使い、その橋には期限を設けてください。具体的には、ディストリに修正済みカーネルがあるなら今すぐ展開を始め、再起動のたびにuname -rを確認します。UbuntuかRHELを使っているなら、今日中にIPオプションの破棄とMPTCPの無効化をデプロイし、欠けているカーネル修正はブロッカーとして扱ってください。トラッカーは週次ではなく日次で確認します。MPTCPリスナーを持つインターネット公開のものを最優先し、次に受信TCPを受け付けるそれ以外すべて、つまりほぼすべてを対象にします。コンテナは守ってくれません。ホストのカーネルを共有しているので、ノードにパッチを当ててください。

より深い教訓は、このバグが新しいCVE番号の下で数年ごとに教えてくれるものです。ミティゲーションは時間を買いますが、穴を塞ぐのはパッチだけであり、ミティゲーションが買う時間はどんどん短くなっています。必要になる前に、安全で高速なカーネルのロールアウトの筋力を鍛えておきましょう。次の4行の修正は、もう誰かのキューに入っているのですから。