LinuxのTCP脆弱性「CVSS 9.8」：上流では修正済み、Ubuntuでは更新を待つサーバーも

ウェブサイトへのアクセスやAPI通信では、多くの場合TCPが使われる。アプリケーションがデータをやり取りする前に、OSのカーネルが「3ウェイハンドシェイク」と呼ばれる接続確立の処理を行う。今回の問題は、アプリケーションの認証処理より手前にある。

Linux Kernel CVE Teamの説明によると、新しいTCPソケットを作る際に、接続要求側が保持していたIPv4オプションの所有権をコピーせずに移す。一方、別のCPUが再送されたSYNパケットを並行して扱い、同じ情報を読み続ける場合がある。 [1]

その情報が読み取り完了前に解放されると、すでに無効となったメモリーをカーネルが参照してしまう。これがuse-after-free（UAF）だ。クラッシュやメモリー破損につながり、条件がそろえばコード実行の起点にもなり得る。

アプリケーション側でログイン認証を設けたりライブラリーを更新したりしても、カーネルのTCP処理に存在する不具合は自動的には解消しない。ただし、ネットワークから不具合を引き起こせることと、あらゆるTCPサービスでroot権限を奪えることは同義ではない。

UAFが存在しても、それだけで攻撃者がシステムを掌握できるわけではない。実際にコードを実行するには、メモリーの位置を突き止め、各種保護機構を越えて実行の流れを制御する追加の手順が必要になる。

10月27日のAnthropicの報告では、未公開の社内Claudeモデルが、MPTCPの待ち受け機能を持つLinuxサーバーに対して一連の攻撃を構築した。MPTCPは、複数のネットワーク経路を一つの論理的なTCP接続に利用できる拡張技術である。 [3][5]

最初の段階では、競合状態を利用してカーネルのアドレス情報を漏えいさせ、メモリー配置をランダム化するKASLRを回避した。次に、同じ不具合を使って関数呼び出しに関わるポインターを書き換え、最終的に攻撃者が指定したシェルコマンドをroot権限で実行したという。 [3]

Anthropicによれば、アドレス情報の取得まで48分、コマンド実行までさらに5分を要した。競合状態の再現に失敗しても、サーバー全体が停止するとは限らず、接続の失敗だけで終わるため再試行が可能だったという。これは研究環境での実証結果であり、実社会での攻撃発生を示す証拠ではない。 [3]

ここで重要なのは、脆弱性そのものはIPv4のTCP処理にある一方、公表されたroot権限の遠隔実行の実証はMPTCPリスナーを使用している点だ。同じ攻撃が通常のTCPリスナーすべてで成立するとは確認されていない。

Linux Kernel CVE Teamは修正を公開し、5.15.223、6.12.113、6.18.56、7.2.10など、保守対象の安定版系列へ取り込んだ。変更の中心は、Read-Copy-Update（RCU）の仕組みを使い、他の処理が読み終えるまで該当メモリーの解放を遅らせることだ。 [1]

ただし、Ubuntuは上流の最新版カーネルをそのまま配布しているわけではない。CanonicalはUbuntuの各リリースやクラウド向けのカーネルパッケージを独自に保守しており、修正の取り込み、検証、配布に時間を要する。

10月30日時点で確認したCanonicalのCVE情報では、Ubuntu 22.04 LTS、24.04 LTS、26.04 LTS、26.10の標準linuxパッケージは、依然として「Vulnerable／修正作業中」と表示されていた。20.04 LTSなど旧版の一部も影響対象とされる。修正予定のパッケージ番号が掲載されていても、利用者がインストールできる更新として公開されたとは限らない。 [2]

上流のソースコードが修正済みでも、本番サーバーで稼働中のカーネルが安全とは限らない。この差が実際の運用リスクになる。ディストリビューションは旧版のカーネルへ修正だけを移植することもあるため、上流のバージョン番号との単純比較では判断できない。

さらに、更新済みパッケージを導入しても、再起動するまでは以前のカーネルが動き続ける場合がある。パッケージの状態と稼働中のカーネルを両方確かめる必要がある。

最初に、対象になり得るサーバーを洗い出し、外部ネットワークからの到達性を確認したい。オンプレミス、クラウドVM、Kubernetesのワーカーノード、インターネット公開サービスも含めて整理する。コンテナーはホストのカーネルを共有するため、アプリケーションのイメージ更新だけではカーネルの修正にならない。

uname -rで稼働中のカーネルを確認したうえで、Canonicalの配布パッケージ名・バージョンをCVE情報と照合する。linux-aws、linux-azure、linux-gcpなどの派生パッケージは、標準カーネルと配布時期が一致しないことがある。

公開されているTCPリスナーと通信元の許可範囲を点検し、不要なポートはファイアウォールやセキュリティグループで制限する。MPTCPを使っている環境では、カーネルが機能をサポートしているかだけでなく、実際にMPTCPリスナーを持つサービスを特定することが重要だ。

MPTCPが業務上不要なら、影響を検証したうえで利用を制限する選択肢はある。ただし、これを完全な修正とみなしてはいけない。根本の問題はTCP/IPv4の処理にあり、公開された実証だけで他の攻撃経路すべてを否定できるわけではない。

並行して、検証環境でのカーネル更新試験、保守時間、ロールバック、段階的な再起動の計画を準備する。対応する修正版が配布されたら適用し、再起動後に修正済みカーネルが実際に動いていることまで確認して初めて対応が完了する。

今回の事例では、アプリケーション自体に不具合がなくても、下位にあるOSのネットワーク処理がリスクになり得ることが明らかになった。Anthropicの研究はAIが複雑な攻撃の構築を支援し得ることも示したが、一つの研究成果から実際の攻撃件数や広がりを推測することはできない。

確認できる事実は、Linuxカーネルに不具合が存在すること、AnthropicがMPTCPを用いた特定の試験環境での成功を報告したこと、そしてディストリビューションが修正を利用者に届けるまでには別の工程が必要だということだ。「UbuntuでTCPポートを開いていれば必ずroot権限を奪われる」という断定は根拠を超える。 [1][2][3]

企業が必要とするのは、CVEの点数だけを見る運用ではない。資産台帳、ネットワークへの公開範囲、業務上の重要度、更新の実施時期、再起動後の検証を一つにつなげることだ。その仕組みがあれば、修正パッケージを待つ期間にも、優先的に守るべきシステムを判断できる。