InfraAcademy Blog

AIがLinuxのroot権限奪取を実証！CVSS 9.8の重大脆弱性「CVE-2026-98432」の仕組みと対策を解説

公開日: 2026-10-31 更新日: 2026-10-31 著者: ryu | #AI #Linux #セキュリティ

Linuxをブラウザで試してみる

Linux・ネットワーク・AWSを、環境構築なしで実践学習できます

こんにちは、インフラエンジニアのryuです。

2026年10月27日、AI開発企業のAnthropicが、AIを利用した脆弱性研究の成果を発表しました。

その中でも特に注目を集めたのが、Linuxサーバーにネットワーク経由でパケットを送ることで、root権限のコマンド実行に成功したという事例です。

対象となったのは、Linuxカーネルに存在する重大な脆弱性「CVE-2026-98432」。深刻度を示すCVSSスコアは9.8と評価されています。

さらに驚くべきことに、Anthropicが公開した検証では、AIが作成した攻撃コードによって、約53分でroot権限によるコマンド実行に到達しています。

ただし、すべてのLinuxサーバーが53分で乗っ取られるという意味ではありません。今回の攻撃は、MPTCPで待ち受ける特定の検証環境で実証されたものです。

今回の脆弱性を理解するうえで重要なのは、単に「Linuxに危険な脆弱性が見つかった」という事実だけではありません。

TCPの接続処理で、なぜメモリの不正な参照が発生したのか
複数のCPUが同時に動作すると、なぜ競合状態が生まれるのか
Use-After-Freeという不具合が、どのようにroot権限でのコード実行につながるのか
Linuxカーネルは、この問題をどのようなコード変更で修正したのか
自分が管理するLinuxサーバーでは、何を確認すればよいのか

この記事では、こうした疑問をLinuxカーネルの修正内容やAnthropicの研究発表をもとに解説します。

TCPの基礎から始め、カーネル内部のデータ構造やメモリ管理の仕組みまで掘り下げるため、Linuxやネットワークを学習中の方はもちろん、実際にサーバーを運用しているエンジニアにも役立つ内容です。

Linuxカーネルの重大脆弱性「CVE-2026-98432」とは？¶

CVE-2026-98432は、LinuxカーネルのIPv4におけるTCP接続処理で発生する、Use-After-Free（UAF）脆弱性です。

Use-After-Freeとは、すでに解放されたメモリを、プログラムが引き続き参照してしまう不具合を指します。

今回の問題はTCPの接続処理とメモリ管理に関係しているため、特別なWebアプリケーションが動作していなくても、影響を受ける可能性があります。

脆弱性の概要¶

項目	内容
CVE番号	CVE-2026-98432
対象	LinuxカーネルのIPv4 TCP処理
脆弱性の種類	Race Condition（競合状態）によるUse-After-Free
影響が導入された系列	Linux 4.4以降
CVSS v3.1	9.8（Critical）
攻撃経路	ネットワーク経由
認証	不要
ユーザー操作	不要
想定される影響	カーネルの異常終了、メモリ破壊、条件次第で遠隔コード実行
修正	Linuxカーネルの各メンテナンス系列に修正を取り込み済み

※2026年10月31日時点の情報です。Linuxディストリビューションによって修正パッケージの公開状況は異なります。

CVSS 9.8は、最高値10.0に非常に近いスコアです。

今回のCVSS評価で注目したいのが、次のベクトルです。

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

それぞれの項目には、次のような意味があります。

項目	評価	意味
AV:N	Network	ネットワーク経由で攻撃できる
AC:L	Low	攻撃の複雑さが低いと評価される
PR:N	None	攻撃前に権限を持つ必要がない
UI:N	None	被害者側の操作が不要
S:U	Unchanged	影響範囲のスコープは変更されない
C:H	High	機密性への影響が大きい
I:H	High	完全性への影響が大きい
A:H	High	可用性への影響が大きい

特に重要なのは、ネットワーク経由で認証なしに攻撃できる可能性がある点です。

ただし、CVSSの「攻撃の複雑さが低い」という評価と、実際に安定した攻撃コードを開発・実行できるかは別の問題です。

今回のような競合状態を利用した攻撃では、CPUの実行タイミングやメモリ配置などによって成功条件が大きく変わります。

深刻度が高い一方で、実際の攻撃成立には技術的な条件があるという点を押さえておきましょう。

なぜTCP通信の処理だけでroot権限の奪取につながるのか？¶

今回の問題を理解するために、まずLinuxにおける「カーネル」と「ユーザー空間」の違いを整理します。

ユーザー空間とカーネル空間の違い¶

Linuxでは、プログラムが動作する領域が大きく2つに分かれています。

領域	役割	動作するプログラムの例
ユーザー空間	通常のアプリケーションを実行	Nginx、Apache、Python、Goなど
カーネル空間	OSの重要な機能を制御	メモリ管理、プロセス管理、TCP/IP処理など

通常のアプリケーションは、カーネルのメモリを直接読み書きできません。

必要な処理は、システムコールを経由してカーネルに依頼します。

一方、TCPのパケット処理はカーネル内部で実行されます。

つまり、ネットワークから届いたデータは、アプリケーションが受け取る前にカーネルによって解析されているのです。

ここで重要なのは、カーネル内部に存在するメモリ破壊の脆弱性は、通常のアプリケーションのバグとは影響範囲が大きく異なるということです。

カーネルの制御を奪われると、OSの保護機構を回避したり、高い権限で処理を実行されたりする可能性があります。

今回の実証では、カーネル内部のメモリ破壊を起点に、最終的にroot権限でシェルコマンドを実行することに成功しました。

ただし、Use-After-Freeが発生しただけで、自動的にroot権限が得られるわけではありません。

その間には、メモリ情報の取得や制御フローの変更といった、複数の技術的な段階があります。

TCPの3ウェイハンドシェイクと「リクエストソケット」¶

今回の脆弱性は、TCPの接続が確立される途中で発生します。

そのため、3ウェイハンドシェイクを理解することが重要です。

TCPの接続確立は3段階で行われる¶

通常、TCPでは次の順番でパケットを交換します。

SYN：接続要求
クライアントからサーバーに対して、TCP接続を開始したいことを伝えます。
SYN-ACK：接続要求への応答
サーバーは接続要求を受け付け、SYNとACKのフラグを設定したパケットを返します。
ACK：接続確立の確認
クライアントがACKを返すことで、TCP接続が確立されます。

この一連の処理を3ウェイハンドシェイクと呼びます。

Linuxでは、最初のSYNを受信した時点で、接続が完全に確立されるわけではありません。

接続確立の途中にある状態を管理するため、カーネルはリクエストソケット（request socket）というデータ構造を利用します。

リクエストソケットと子ソケット¶

リクエストソケットは、TCP接続が確立するまでの一時的な状態を保持するためのデータ構造です。

通常の接続確立では、次のような処理が行われます。

サーバーがクライアントからSYNパケットを受信する。
カーネルが接続要求を管理するためのリクエストソケットを用意する。
サーバーがSYN-ACKを送信する。
クライアントからACKが届く。
カーネルが実際の通信に利用する子ソケットを作成する。
接続が確立し、アプリケーションが通信できる状態になる。

ここで重要なのは、リクエストソケットと子ソケットが異なる役割を持っていることです。

リクエストソケットは接続確立途中の情報を管理し、子ソケットは接続確立後の通信を担当します。

今回の脆弱性に関係しているのが、この2つのソケット間でデータを引き継ぐ処理です。

IPv4のIPオプションが問題に関係する¶

IPv4パケットのヘッダーには、IPオプションという可変長の領域があります。

今回関係するのは、次のようなオプションです。

Record Route： パケットが通過したルーターのIPアドレスを記録する機能
Timestamp： パケットが通過した際の時刻などを記録する機能

どちらも現在の一般的なネットワーク通信では使用頻度が高くありません。

なお、ここで説明しているTimestampは、TCPのTimestampオプションとは異なり、IPv4ヘッダーに存在する機能です。

Linuxカーネルは、SYNパケットに含まれるIPv4オプションを保存し、応答パケットを生成するときに利用することがあります。

そのため、TCP接続の途中でもIPv4オプションのメモリを参照する処理が存在します。

今回の脆弱性では、このデータの寿命を適切に管理できていなかったことが問題になりました。

原因は競合状態によるUse-After-Free¶

ここからは、Linuxカーネルの内部処理を詳しく見ていきます。

今回の脆弱性を理解するための重要なキーワードは、次の3つです。

メモリの所有権（Ownership）
競合状態（Race Condition）
Use-After-Free（UAF）

1. メモリの所有権が子ソケットへ移動する¶

LinuxカーネルのIPv4 TCP処理には、tcp_v4_syn_recv_sock()という関数があります。

この関数は、TCP接続が確立する際に子ソケットを生成する処理に関係しています。

今回の不具合では、リクエストソケットが保持するIPv4オプションが、子ソケットへ引き継がれることが重要です。

代表的なメンバーは次のとおりです。

データ	意味
`ireq->ireq_opt`	リクエストソケット側のIPv4オプション
`newinet->inet_opt`	子ソケット側のIPv4オプション

接続確立時には、オプションを新しいメモリに複製するのではなく、所有権を子ソケットへ移す処理が行われます。

このとき、別のCPUがすでに同じオプションを参照している場合が問題になります。

なぜなら、データの所有権が移動したことと、ほかのCPUによる参照が終わったことは同じではないからです。

2. 複数のCPUが同時にTCP接続を処理する¶

近年のLinuxサーバーでは、複数のCPUコアによってネットワーク通信を並列処理しています。

高負荷なサーバーでも効率的にTCP接続を処理できる一方、共有データに対するアクセスには注意が必要です。

今回の問題を単純化すると、次のような流れになります。

CPU AがTCP接続確立処理を開始する。
クライアントからACKが届き、子ソケットの生成処理が進みます。
CPU Bが同じ接続に関する再送SYNを処理する。
CPU Bは、リクエストソケットに関連するIPv4オプションを参照してSYN-ACKを作成しようとします。
CPU AがIPv4オプションの所有権を子ソケットへ移動する。
メモリをコピーするのではなく、既存の領域を子ソケットへ引き継ぎます。
CPU Aが子ソケットの後処理を行う。
子ソケットの解放処理によって、IPv4オプションのメモリも解放される場合があります。
CPU Bが同じメモリを参照する。
CPU Bによる読み取りがまだ完了していないと、すでに解放されたメモリにアクセスしてしまいます。

このように、複数の処理の実行順序によって結果が変化する不具合を、Race Condition（競合状態）と呼びます。

今回の問題では、CPU AとCPU Bが、それぞれ個別には正しく見える処理を実行していても、そのタイミングが重なることでメモリの安全性が失われていました。

これはマルチスレッドプログラミングや並行処理でも共通する問題です。

3. 解放済みメモリへのアクセスが発生する¶

Linuxカーネルはメモリを確保したり、不要になったメモリを解放したりしています。

ここで重要なのが、kfree()という関数です。

kfree()は、カーネル内で動的に確保されたメモリを解放するために使用されます。

解放されたメモリ領域は、その後、別のデータの保存先として再利用される可能性があります。

もしプログラムが解放済みのメモリを参照すると、次のような問題が発生します。

すでに存在しないデータを読み取ってしまう
別の用途で使われ始めたメモリを誤って参照する
不正なアドレスを参照してカーネルが異常終了する
メモリの内容によっては、想定外の書き込みが発生する

特にカーネル空間でのUse-After-Freeは、システム全体の動作に影響する可能性があるため危険です。

なぜLinuxカーネルのRCUでは防げなかったのか？¶

今回の脆弱性で、技術的に非常に興味深いのがRCU（Read-Copy-Update）の扱いです。

RCUは、Linuxカーネルで使用されている並行処理のための同期機構です。

読み取り処理が多いデータ構造において、ロックによる競合を減らし、効率よくアクセスするために利用されます。

RCUとは？¶

RCUの重要な考え方は、あるCPUがデータを読み取っている間、そのデータを参照できなくなるようなメモリ解放を行わないことです。

例えば、あるデータをCPU Aが読み取っているとします。

その間にCPU Bがデータを削除しようとしても、CPU Aが安全に読み取りを終えるまで、メモリの回収を遅らせることができます。

処理を順番に整理すると、次のようになります。

CPU AがRCUの読み取り区間に入る。
rcu_read_lock()などを利用して、RCUによって保護されたデータを参照します。
CPU Bがデータを更新・削除する。
既存のデータを参照元から切り離し、新しい読み取り処理が古いデータにアクセスしない状態を作ります。
CPU Bがメモリの回収を遅らせる。
既存の読み取り処理が終了するまでは、古いデータを保持します。
CPU Aが読み取りを終了する。
rcu_read_unlock()によって読み取り区間を終了します。
RCUの猶予期間が経過する。
既存の読み取り処理が終了したことを確認できた後、古いメモリを安全に回収できます。

ここでいうGrace Period（猶予期間）は、既存のRCU読み取り処理が完了したことを保証するための期間です。

注意したいのは、RCUが一般的な排他ロックと同じ仕組みではないという点です。

通常のMutexなどの排他ロックは、ある処理がロックを保持している間、ほかの処理による特定の操作を制限します。

一方、RCUでは読み取り処理をできるだけ停止させずに実行できることが重要です。

その代わり、データを更新・削除する側は、古いデータを参照している処理が存在する可能性を考慮する必要があります。

読み取り側がRCUを使っていても安全とは限らない¶

今回のLinuxカーネルでは、IPv4オプションを参照する側はRCUの仕組みを利用していました。

たとえば、以下の関数が関係しています。

tcp_v4_send_synack()
inet_csk_route_req()
ip_options_build()

ところが、問題となった解放側の処理では、RCUの猶予期間を待たずにkfree()が呼ばれていました。

つまり、読み取り側はRCUによって保護されているつもりでも、解放側がその約束を守っていなかったのです。

これは、並行プログラミングで非常に重要な教訓です。

読み取り側だけを正しく実装しても、更新側や解放側が同じ同期ルールを守らなければ、メモリ安全性は保証されません。

2015年の変更が競合状態を生み出していた¶

今回の問題には、2015年に行われたLinuxカーネルの変更も関係しています。

該当する変更は次のコミットです。

079096f103fa

コミット名は以下です。

tcp/dccp: install syn_recv requests into ehash table

この変更以降、TCP接続確立途中のリクエストソケットが、リスナーのロックを保持せずに処理されるようになりました。

これは接続処理の並列性に関係する変更ですが、別のCPUによる処理と、子ソケットの解放が並行して進む条件も生み出しました。

その結果、IPv4オプションを読み取る処理と解放する処理が重なる可能性が生まれました。

問題のコードが約10年間残っていたことも、今回の脆弱性が注目された理由の一つです。

AIはどのようにしてroot権限のコマンド実行に成功したのか？¶

ここまで説明したUse-After-Freeは、あくまでメモリ管理上の不具合です。

では、なぜこの不具合からroot権限によるコマンド実行まで到達できたのでしょうか。

Anthropicの発表によると、攻撃には大きく2つの段階がありました。

第1段階：カーネルのメモリ情報を取得し、KASLRを回避¶

現代のLinuxカーネルには、KASLR（Kernel Address Space Layout Randomization）という保護機構があります。

KASLRは、カーネルや関連するコード・データが配置される仮想メモリアドレスをランダム化する仕組みです。

攻撃者がメモリ破壊を引き起こせたとしても、標的となるコードやデータがどこに配置されているのか分からなければ、安定した攻撃は難しくなります。

今回、AIが生成した攻撃コードは、このKASLRを回避するため、最初にカーネルのアドレス情報を取得しました。

その起点となったのが、Use-After-Freeによって不正な内容になったIPv4オプションのメモリです。

Linuxカーネルのip_options_build()は、IPv4オプションを組み立てる際に、オプションの長さを示すoptlenなどの情報を利用します。

解放済みのメモリが再利用され、長さに関する値が想定外の内容になっていた場合、通常より多いメモリ内容が応答パケットに含まれる可能性があります。

Anthropicの攻撃コードは、この挙動を利用してカーネルのメモリに存在するポインタ情報を取得しました。

カーネル内部のポインタには、実際のメモリ配置を推測するための情報が含まれている場合があります。

これにより、次の段階で必要となるカーネルのアドレス情報を得ることができました。

なお、KASLRの回避は、それ自体がroot権限の奪取を意味するわけではありません。

これは、後続のメモリ破壊攻撃を成功させるための重要な準備段階です。

第2段階：メモリ破壊を利用してカーネルの制御フローを変更¶

続いて攻撃コードは、同じUse-After-Freeを利用し、メモリへの不正な書き込みにつながる状態を作り出しました。

Anthropicの説明によると、攻撃コードはバッファの範囲外への書き込みを利用して、カーネル内部のコールバックポインタを書き換えています。

コールバックポインタとは、後から実行される関数のアドレスを保持するための情報です。

通常、カーネルはこのポインタを利用して、あらかじめ想定された処理を呼び出します。

しかし、メモリ破壊によって参照先が書き換えられると、意図しない処理へ制御が移る可能性があります。

今回の攻撃では、カーネル内に事前に配置した処理へ制御を移し、既存のカーネル関数を組み合わせて、最終的にroot権限のシェルコマンドを実行しました。

攻撃の全体的な流れ¶

今回の攻撃を技術的な段階に分けると、次のようになります。

ネットワーク経由でTCP接続処理に到達する。
カーネルがTCP接続を処理する際のメモリ管理上の不具合が攻撃の起点となります。
複数CPUの処理が競合する。
接続確立処理と再送SYNの処理が重なり、メモリの寿命管理に不整合が生じます。
Use-After-Freeが発生する。
解放されたメモリが参照され、意図しない内容が読み取られる状態になります。
カーネル内部のメモリ情報を取得する。
応答パケットを通じた情報漏洩によって、KASLRの回避に必要な情報を取得します。
メモリ破壊によって制御フローを変更する。
不正な書き込みを利用して、カーネル内部で実行される処理の参照先を変更します。
root権限によるコマンド実行に到達する。
カーネル内部の処理を悪用することで、管理者権限でのコマンド実行が実証されました。

この事例で重要なのは、単一の不具合だけで攻撃が完成したわけではないという点です。

実際には、情報漏洩、アドレスの特定、メモリ破壊、制御フローの変更という複数の技術を組み合わせています。

特にカーネルのUse-After-Freeを安定した遠隔コード実行へつなげることは、一般的に高度な技術を必要とします。

Anthropicの研究が注目されたのは、こうした複数段階の攻撃を、AIが実際に動作するコードとして構築したことにあります。

約53分という時間は何を意味するのか？¶

Anthropicの公開した検証では、次の時間が報告されています。

段階	所要時間
カーネルのポインタ情報の取得	約48分
コマンド実行への到達	追加で約5分
合計	約53分

この約53分は、作成された攻撃コードを実行してから成功するまでの時間です。

AIが脆弱性の調査から攻撃コードの開発までを53分で終えたという意味ではありません。

また、競合状態の攻撃では、対象環境によって実行タイミングや成功率が変わります。

そのため、すべてのLinuxサーバーが同じ時間で攻撃されるわけではありません。

今回の検証では、競合状態が成立しなかった場合でも、多くはTCP接続の確立に失敗するだけで、直ちにシステム全体が停止するわけではないという特徴がありました。

これにより、攻撃コードが成功するまで繰り返し試行できる条件が存在しました。

ただし、Use-After-Freeはカーネルの異常終了につながる可能性もあり、失敗した攻撃が常に無害ということではありません。

Linuxカーネルはわずか2行の変更で脆弱性を修正した¶

今回の脆弱性は、原因と修正内容を比較することで、RCUの重要性を理解しやすい事例です。

修正コミットでは、2つのソースファイルにおいて、メモリを解放する処理が変更されました。

修正前：kfree()でメモリを解放¶

修正前の処理では、次のようにkfree()を利用していました。

kfree(rcu_dereference_protected(inet->inet_opt, 1));

kfree()による解放では、ほかのCPUがRCUの読み取り区間で同じメモリを参照していても、その読み取りの完了を待つ仕組みにはなっていません。

そのため、解放済みメモリへのアクセスが発生する可能性がありました。

修正後：kfree_rcu()で安全に解放¶

修正後は、次のように変更されています。

kfree_rcu(rcu_dereference_protected(inet->inet_opt, 1), rcu);

kfree_rcu()は、RCUの猶予期間が経過した後にメモリを解放するための仕組みです。

これにより、既存のRCU読み取り処理が完了する前に、対象のメモリが回収されることを防ぎます。

単純化すると、次の違いがあります。

関数	メモリ解放の考え方
`kfree()`	RCU読み取り側の終了を待たずに解放する
`kfree_rcu()`	RCUの猶予期間後に解放する

なお、kfree_rcu()は、呼び出し元の処理を長時間停止させて待機するものではありません。

RCUの仕組みを利用して、メモリの回収を後のタイミングに遅らせます。

修正されたソースファイル¶

今回のパッチでは、主に次の2か所が変更されています。

ファイル	関数	役割
`net/ipv4/af_inet.c`	`inet_sock_destruct()`	IPv4ソケットの後処理
`net/ipv4/tcp_ipv4.c`	`tcp_v4_reqsk_destructor()`	TCPリクエストソケットの後処理

どちらも、RCUの読み取り側が参照する可能性のあるメモリを解放する処理です。

修正がわずか2行だったとしても、その影響は決して小さくありません。

カーネルのメモリ管理では、どのCPUがデータを参照しているか、誰が所有権を持つか、いつ安全に解放できるかという設計が非常に重要です。

もう一つの問題：リクエストソケットの移行¶

今回の修正には、TCP接続確立時の処理とは別に、リクエストソケットの移行に関係する問題も含まれています。

Linuxには、SO_REUSEPORTを利用して複数のプロセスやソケットで同じポートを扱う機能があります。

さらに、一定の条件下では、接続途中のリクエストソケットを別のリスナーへ移行できます。

これに関係する設定が、次の項目です。

net.ipv4.tcp_migrate_req

また、eBPFのBPF_SK_REUSEPORT_SELECT_OR_MIGRATEを利用する構成も関係します。

この移行処理では、元のリクエストソケットと複製されたリクエストソケットが、一時的に同じIPv4オプションを参照する場合があります。

その状態で片方のソケットが解放されると、もう片方が解放済みのメモリを参照する可能性がありました。

今回の修正では、この経路におけるメモリ解放もRCUに対応させています。

この点からも、CVE-2026-98432を単純に「MPTCPだけの脆弱性」と考えるべきではありません。

IPv6は影響を受けるのか？¶

今回の主な問題はIPv4のTCP処理にあります。

IPv6のTCP接続確立処理では、オプションを複製して引き継ぐため、今回説明した子ソケットへの所有権移動に関する問題とは異なります。

ただし、Linuxカーネルの公式な説明では、IPv6にもCALIPSOオプションを利用するリクエストソケット移行経路の類似問題があることが示されています。

そのため、「IPv6なら今回に関連する問題が一切存在しない」と判断するのは適切ではありません。

MPTCPとは？なぜGoで作ったサーバーも注意が必要なのか¶

Anthropicが公開した攻撃実証では、MPTCPで待ち受けるLinuxサーバーが対象となっていました。

MPTCPは、Multipath TCPの略称です。

通常のTCP接続が基本的に1つの通信経路を利用するのに対し、MPTCPでは1つの論理的な接続の中で、複数のTCPサブフローを利用できます。

たとえば、Wi-Fiとモバイル通信など、複数のネットワーク経路を組み合わせた通信に利用できます。

MPTCPを有効化していなくても使われている可能性がある¶

ここで注目したいのが、Go言語です。

Go 1.24では、Linux上でのネットワーク待ち受けに関して、MPTCPを既定で利用する動作が導入されました。

Goのnetパッケージは、HTTPサーバーなど多くのネットワークアプリケーションで利用されています。

そのため、開発者がMPTCPを明示的に指定していなくても、実行環境やアプリケーションの設定によっては、MPTCPの待ち受けが使用される可能性があります。

Goのセキュリティチームも、2026年10月29日にこの脆弱性への注意喚起を行っています。

重要なのは、MPTCPが今回の脆弱性そのものではないという点です。

根本的な不具合はIPv4 TCP処理のメモリ管理にあり、MPTCPはAnthropicが攻撃を実証した際の条件です。

Goチームは、MPTCPを使っていないサーバーでも、同様の問題を利用した攻撃が成立する可能性を指摘しています。

したがって、MPTCPを無効化するだけで、今回の脆弱性を完全に解消できるわけではありません。

自分のLinuxサーバーは大丈夫？確認方法と対策¶

ここからは、実際にLinuxサーバーを管理している方向けの内容です。

まずは現在の状態を確認し、その後で修正パッケージの適用状況を調べましょう。

1. 現在動作しているカーネルを確認する¶

最初に確認するのが、実行中のLinuxカーネルのバージョンです。

uname -r

uname -rは、現在動作しているカーネルのリリース情報を表示します。

今回の脆弱性について、Linuxの各系列で最初に修正が取り込まれたバージョンは、次のとおりです。

カーネル系列	最初の修正済みバージョン
5.10	5.10.272
5.15	5.15.223
6.1	6.1.190
6.6	6.6.159
6.12	6.12.113
6.18	6.18.56
7.2	7.2.10
7.3	正式リリース時点で修正済み

ただし、ここで注意点があります。

Ubuntu、Debian、RHELなどのディストリビューションでは、古いカーネル系列を維持したまま、必要な修正だけを取り込むバックポートという方法が採用されています。

たとえば、uname -rで表示されたバージョン番号が古く見えても、ディストリビューションが必要なセキュリティ修正を取り込んでいる場合があります。

そのため、バージョン番号だけで脆弱性の有無を断定しないでください。

2. ディストリビューション別に修正状況を確認する¶

2026年10月31日時点では、主要ディストリビューションでの対応状況に違いがあります。

ディストリビューション	公開されている対応状況
Debian 12	修正済みパッケージあり
Debian 13	修正済みパッケージあり
Ubuntu 22.04 LTS	修正作業中
Ubuntu 24.04 LTS	修正作業中
Ubuntu 26.04 LTS	修正作業中
RHEL 8・9・10	影響対象。修正状況は公式アドバイザリで確認

実際に対応する際は、利用しているOSのセキュリティアドバイザリを確認することが重要です。

カーネルの更新では、パッケージをインストールしただけでは、実際に動作しているカーネルが切り替わらないことがあります。

通常の更新では、修正済みカーネルを起動するために再起動が必要です。

再起動後は、もう一度uname -rを実行して、動作中のカーネルを確認しましょう。

※Linux Livepatchなど、再起動なしで修正を適用する仕組みを利用している場合は、提供元の案内に従って適用状態を確認してください。

3. MPTCPが有効か確認する¶

Linuxでは、次のコマンドでMPTCPの設定状態を確認できます。

sysctl net.mptcp.enabled

表示例は次のとおりです。

net.mptcp.enabled = 1

1は、そのネットワーク名前空間でMPTCPソケットを作成できる状態を意味します。

一方、0は無効を意味します。

この設定が1だからといって、実際にすべてのTCP通信がMPTCPを使っているわけではありません。

次に、MPTCPのソケットを確認します。

sudo ss -lMnp

ssはソケットの状態を確認するためのコマンドです。

主なオプションは次のとおりです。

オプション	意味
`-l`	待ち受け中のソケットを表示
`-M`	MPTCPソケットを対象にする
`-n`	ポート番号などを数値で表示
`-p`	関連するプロセス情報を表示

MPTCPの待ち受けが存在する場合は、利用しているプログラムやポートを確認してください。

なお、ssのバージョンや権限、ネットワーク名前空間によって取得できる情報は異なります。

何も表示されなかった場合でも、脆弱性が存在しないことを証明するものではありません。

4. リクエストソケット移行の設定も確認する¶

今回の脆弱性では、TCPリクエストソケットの移行処理も関係しています。

次のコマンドで設定を確認できます。

sysctl net.ipv4.tcp_migrate_req

通常の既定値は0です。

ただし、eBPFによるリクエストソケットの移行処理を利用している構成もあるため、この値だけで関連経路の有無を完全に判断できるわけではありません。

SO_REUSEPORTやeBPFを利用して高度な負荷分散を実装している場合は、アプリケーションの構成も含めて確認しましょう。

5. 修正版カーネルが利用できない場合の一時的な緩和策¶

修正版への更新が最も重要な対策ですが、業務上の都合ですぐに更新できない場合もあります。

その場合、実証された攻撃条件の一つであるMPTCPを無効化する方法が考えられます。

設定コマンドは次のとおりです。

sudo sysctl -w net.mptcp.enabled=0

再起動後も設定を維持する場合は、次のように設定ファイルを作成します。

echo 'net.mptcp.enabled = 0' \
  | sudo tee /etc/sysctl.d/90-disable-mptcp.conf

ただし、運用中のシステムで無条件に実行することはおすすめしません。

MPTCPに依存しているプログラムでは、通信が正常に行えなくなる可能性があります。

特にGoで実装したサーバーでは、既存の待ち受けソケットや新規接続への影響を含めて、動作確認と必要なサービス再起動を計画する必要があります。

Goでは、次の環境変数によってMPTCPの既定動作を変更できます。

GODEBUG=multipathtcp=0

ただし、アプリケーションが明示的にMPTCPを有効化している場合など、環境変数だけでは十分でないことがあります。

Goチームも、アプリケーションごとのMPTCP無効化は見落としが生じやすく、脆弱性の修正そのものにはならないと説明しています。

MPTCPの無効化は暫定的なリスク低減策であり、修正版カーネルへの更新の代わりにはなりません。

DockerやKubernetesで動いている場合は？¶

今回の脆弱性は、アプリケーションではなくLinuxカーネルに存在する問題です。

そのため、DockerやKubernetesを利用している環境でも注意が必要です。

一般的なLinuxコンテナは、ホストOSのLinuxカーネルを共有しています。

つまり、コンテナ内のアプリケーションを更新したり、コンテナイメージを新しくしたりしても、ホストのカーネルに存在する脆弱性が自動的に修正されるわけではありません。

たとえば、Linuxホスト上でNginxのコンテナとGoアプリケーションのコンテナが動いている場合を考えます。

ホストOSにはLinuxカーネルが存在します。
Nginxのコンテナは、このホストカーネルを利用して通信します。
Goアプリケーションのコンテナも、同じホストカーネルを利用します。
コンテナイメージを更新しても、ホストカーネルは原則としてそのままです。
ホストカーネルに脆弱性が残っている場合は、ホスト側で対策する必要があります。

Kubernetesでは、Podの再作成だけでなく、ノードのカーネル更新が必要になる場合があります。

クラウド環境であれば、OSイメージやマネージドノードの更新状況も確認する必要があります。

なお、ホストカーネルの管理をクラウド事業者が行うサービスでは、責任分界や更新方法が異なります。

攻撃の痕跡はログから確認できるのか？¶

セキュリティ担当者にとって気になるのは、すでに攻撃を受けていないかという点でしょう。

今回の脆弱性はカーネルのTCP接続処理に関係するため、通常のWebサーバーのアクセスログだけですべてを判断することはできません。

たとえば、NginxやApacheのアクセスログは、基本的にアプリケーション層で処理されたHTTPリクエストなどを記録します。

しかし、今回の問題はTCP接続の確立途中に発生する可能性があります。

つまり、HTTPリクエストが成立する前に、カーネル側で不具合が発生することも考えられます。

カーネルログを確認する¶

システムの異常終了やメモリ関連のエラーを調査する際には、カーネルログが参考になります。

たとえば、次のコマンドです。

sudo journalctl -k --since "2026-10-20"

journalctl -kはカーネル由来のログを表示します。

調査時には、次のようなエラーメッセージが参考になる場合があります。

BUG:
Oops
general protection fault
kernel panic
KASAN
use-after-free

これらはLinuxカーネルで問題が発生した際に現れることがあるメッセージです。

ただし、表示されたからといって今回の脆弱性による攻撃と断定できるわけではありません。

また、メモリ破壊に関係する問題が発生しても、必ずしもログが残るとは限りません。

SYNの再送や接続失敗も単独では証拠にならない¶

今回の脆弱性では、TCP接続処理の競合が重要な要素となっています。

そのため、ネットワーク監視でSYNの再送や接続失敗が多く観測された場合、調査の参考になる可能性はあります。

ただし、SYN再送は通常のネットワーク障害やパケットロスでも発生します。

それだけをもって攻撃と判定することはできません。

現時点で、一般的なサーバーに対して今回の攻撃を確実に識別できる汎用的なログパターンが示されているわけではありません。

まずはカーネルの修正状態と公開しているネットワークサービスを確認し、必要に応じてネットワークログや異常終了の履歴を組み合わせて調査することが重要です。

AIが脆弱性を攻撃コードに変える時代、何が変わるのか？¶

今回のニュースで興味深いのは、Linuxの脆弱性そのものだけではありません。

Anthropicの研究では、AIが脆弱性を調査し、複数の攻撃技術を組み合わせて実際に動作する攻撃コードを構築できることが示されました。

従来、カーネルのUse-After-Freeを利用した高度な攻撃コードの開発には、Linuxカーネルの内部構造、CPUの並列処理、メモリ管理、アセンブリやバイナリ解析など、幅広い知識が必要でした。

AIがこうした作業を支援できるようになることで、脆弱性の発見から実用的な攻撃手法の構築までの過程が変化する可能性があります。

ただし、AIが存在するだけであらゆる脆弱性を簡単に悪用できるようになったわけではありません。

今回の事例は、AIを利用した高度な研究環境での実証結果です。

それでも、防御側のエンジニアにとって重要な示唆があります。

修正パッチが公開された脆弱性について、攻撃手法が高度だからといって、対応を後回しにできるとは限らないということです。

特にインターネットに公開しているサーバーでは、重要な脆弱性情報の収集、影響確認、パッチ適用、再起動までを一連の運用として管理する必要があります。

今回の脆弱性からインフラエンジニアが学べること¶

CVE-2026-98432は、Linuxカーネルの高度なセキュリティ問題ですが、基礎的なネットワーク知識とも密接に関係しています。

TCPの基礎知識が実際の脆弱性分析につながる¶

今回の攻撃では、SYN、SYN-ACK、ACKというTCPの3ウェイハンドシェイクが重要な役割を持っていました。

これらはCCNAなどのネットワーク学習で登場する基本的な知識です。

しかし、接続確立の仕組みをさらに深く理解すると、次のような技術的なテーマへつながります。

TCPの接続状態とカーネル内部のデータ構造
接続要求の再送処理
ソケットの生成と破棄
マルチコアCPUによる並列処理
メモリ管理と同期機構
RCUを利用した並行処理

単にコマンドやプロトコルの名前を覚えるだけでなく、「OSの内部では実際にどのような処理が動いているのか」を意識して学ぶことが、インフラエンジニアとしての理解を深めることにつながります。

サーバー運用では、脆弱性の確認方法も重要¶

今回紹介したコマンドも、日常的なLinuxサーバー運用で役立つものです。

コマンド	確認できること
`uname -r`	動作中のカーネルバージョン
`sysctl`	カーネルパラメータ
`ss`	TCPなどのソケット情報
`journalctl -k`	カーネルログ