Linuxカーネルの欠陥の続報――Red Hatは修正版を公開、Ubuntuは⁠試⁠験⁠中

LinuxカーネルのIPv4のTCP処理にある欠陥（CVE-2026-98432）について、10月30日の記事から、状況が動きました。Red Hatは、修正版を出しました。Ubuntuは、修正版を、試験用の場所に置きました。そして、10月30日の記事に書いた対処の一つは、書き直す必要があり⁠ま⁠す⁠。

この記事は、変わった点と、いま確認することを、各社の原文で整理したものです。情報は、2026年11月6日の時点のものです。各社のページは、それぞれ更新の日付が違うため、記述のそばに日付を添えま⁠し⁠た⁠。

日本語で出回っている情報には、原文と異なる訳や要約が、かなり見受けられます。この記事は、一次情報を私たちも原文で確認して書いていますが、読者の皆さんも、各社の原文でのご確認をお勧めし⁠ま⁠す⁠。

要点

• Red Hatは、11月1日に、RHEL 8、9、10の修正版を、勧告（RHSA）で公開しました。反映には、再起動が必要です（RHSA-2026:93414、93412、9341⁠3⁠）⁠。
• Ubuntuは、22.04、24.04、26.04の修正版を、11月2日に、試験用の場所（-proposed）に置きました。通常の更新には、まだ出ていません。20.04以前は、修正待ちです（Ubunt⁠u⁠）⁠。
• 「MPTCPを止める」だけでは、足りません。Red Hatは、これを「完全な緩和策ではない」とし、Ubuntuは、適切な緩和策は、セキュリティ更新だけとしています（Red Hat、Ubunt⁠u⁠）⁠。
• 修正版が使えない間の対処として、Red Hatは、IPv4のオプション付きのTCPの通信を落とす、nftablesの設定を公開しました。ただし、これも、完全ではありません（Red Ha⁠t⁠）⁠。
• 実際の攻撃は、CISAのKEVに、まだ登録されていません（2026年11月4日の版を、こちらで直接確認）。ただし、研究者が、「この欠陥を探していると疑われる」インターネット全体への探りを、11月2日から観測した、と投稿しています。攻撃の成功の報告では、ありま⁠せ⁠ん⁠。

10⁠月⁠30⁠日から、変わっ⁠た⁠こ⁠と

10月30日の記事の、MPTCPを止める対処と、Red Hatの記述は、この記事の内容に合わせて、更新しま⁠し⁠た⁠。

Red Hat：修正版は、出て⁠い⁠ま⁠す

Red Hatは、11月1日に、RHELの3つの版の修正版を、公開しま⁠し⁠た⁠。

3つとも、CVE-2026-98432の修正を含みます。RHEL 9の勧告には、複数の延長サポートの系統（EUSなど）も含まれます。自分のマイナーバージョンの修正が、どの番号になるかは、勧告の表で確認してください（私は、RHEL 9の勧告の、前半しか読めていませ⁠ん⁠）⁠。

深刻度は、勧告の間で、そろっていません（RHEL 8がCritical、9と10がImportant）。理由は、確認できていま⁠せ⁠ん⁠。

気をつけたいのは、Red Hatの別のページです。セキュリティ速報（RHSB-2026-016）は、11月4日に更新されていますが、本文は「修正版の公開を急いでいる」のままで、勧告の番号が書かれていません（Red Hat）。勧告は、11月1日の日付で、実在します。この食い違いの理由は、確認できていません。修正が出ているかは、速報ではなく、個別の勧告で確認してくだ⁠さ⁠い⁠。

速報には、次のことも書かれています（Red Ha⁠t⁠）⁠。

• RHELは、既定の設定では、MPTCPが無効です。それでも、影響を受⁠け⁠ま⁠す
• OpenShift Container Platform 4（RHEL CoreOS）は、影響を受けます。OpenStackや仮想化など、RHELのカーネルを使う製品も、影響を受ける可能性があ⁠り⁠ま⁠す
• kernel-rt（リアルタイム用のカーネル）は、速報に、記載があり⁠ま⁠せ⁠ん

Ubuntu：「試験中」の段⁠階⁠で⁠す

Canonicalは、11月2日に、修正版を、試験用の場所（-proposed）に置いた、と書いています（Ubunt⁠u⁠）⁠。

-proposedにあるものは、通常の更新では、入りません。明示的に指定して、入れる必要があります。通常の更新に移る時期は、示されていません。2,000台を超える認定済みの機器での、確認が終わってからとされています（Ubuntu）。Ubuntuの追跡ページでも、クラウド、FIPS、リアルタイムなどの派生カーネルは、作業中の扱いです（Ubuntu、11月5日の更⁠新⁠）⁠。

なお、10月30日の記事の時点では、Ubuntuは、全リリースが「脆弱で、作業中」でした。そこからは、前に進んでい⁠ま⁠す⁠。

「MPTCP⁠を切れば安全」で⁠は⁠な⁠い

10月30日の記事の「更新できないときの、つなぎの対処」に、私は「MPTCPを止める」を、一番に書きました。実証の前提がなくなる、という理由です。これは、弱すぎる対処で⁠し⁠た⁠。

• Red Hat：MPTCPを止めることは「完全な緩和策ではない」。Red Hatは、Anthropicが実証した、一つの構成の話にすぎない、という書き方です（Red H⁠a⁠t⁠）
• Ubuntu：修正は、MPTCP専用ではありません。MPTCPを切る助言は、攻撃の実証がMPTCPを使った、という点だけに基づく、としています。適切な緩和策は、セキュリティ更新だけ、という立場です（Ubun⁠t⁠u⁠）
• Akamai（11月2日）：欠陥の条件は、IPv4のTCPの待ち受けと、IPオプション付きのSYNと、その再送だけです。MPTCPが要るのは、Anthropicが実証した、攻撃のほうです。MPTCPを止めるだけでは、攻撃を防げず、競合を起こしにくくするだけ、としています（Akam⁠a⁠i⁠）

Akamaiは、もう一つの経路も挙げています。リクエストソケットの移行が有効な場合にも、似た経路があります。有効にする設定は、次のどちらかです（Akama⁠i⁠）⁠。

net.ipv4.tcp_migrate_req=1

もう一つは、BPFプログラムによる指定です。Akamaiは、独自に攻撃を試したのではなく、Anthropicの説明に基づいてい⁠ま⁠す⁠。

MPTCPを止める手順は、無駄ではありません。実証の前提を消す効果は、あります。ただし、それだけで「対応済み」にはしないでくだ⁠さ⁠い⁠。

つなぎの対処：IP⁠オプションを⁠落⁠と⁠す

Red Hatは、修正版を入れるまでの対処として、IPv4のオプション付きのTCPの通信を、受信の段階で落とす設定を公開しました。次の内容です（Red Hatの、原文のとお⁠り⁠）⁠。

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

上の設定を、ファイルに保存して、文法を確認してから、適用します。外すのは、修正版を入れたあと⁠で⁠す⁠。

# 文法の確認（ファイル名は、Red Hatの例のとおり）
sudo nft --check --file cve-2026-98432.nft
# 適用
sudo nft --file cve-2026-98432.nft
# 修正版を入れたあとに、外す
sudo nft delete table inet cve_2026_98432

Red Hat自身が、次の点を書いています（Red Ha⁠t⁠）⁠。

• 再起動すると、消えます。修正版を入れる前に再起動した場合は、もう一度、適用が必⁠要⁠で⁠す
• 必要な通信を落とす可能性があります。本番の前に、検証の環境で試してく⁠だ⁠さ⁠い
• 緩和であって、修正の代わりではあり⁠ま⁠せ⁠ん
• OpenShiftでは、ノードのホストの通信にだけ効きます。Pod同士の通信は、対象⁠外⁠で⁠す

ほかに、私が読んだ範囲では、次の注意が、別の資料にあります。転送する通信が対象になる点と、IPオプションが通常の通信になる、CIPSO（SELinuxなどのラベル付きネットワーク）の環境で使えない点です。これらは、Red Hatの速報には、書かれていません（RFF。個人のブログで、公式の案内ではありませ⁠ん⁠）⁠。

Ubuntuのセキュリティチームの、この件の記事には、この設定の記述が、ありません。UbuntuのCVEのページには、コミュニティから寄せられた、同様の対処が載っています。ただし、公式の修正ではない、と注記されています（Ubunt⁠u⁠）⁠。

いま、や⁠る⁠こ⁠と

RH⁠E⁠L⁠系

RHEL、AlmaLinux、Rocky Linux、Oracle Linuxなど⁠で⁠す⁠。

1. 公開しているサーバーから、先に、修正版を入れます。sudo dnf update kernelのあと、再起動⁠し⁠ま⁠す
2. uname -rで、再起動後のカーネルが、上の表の版以上であることを確認します（自分のマイナーバージョンの番号は、勧告で確認し⁠ま⁠す⁠）
3. AlmaLinux、Rocky Linux、Oracle Linuxなどの互換のディストリビューションは、それぞれの告知で確認してください（私は、これらの各社の状況を、直接確認していま⁠せ⁠ん⁠）

Ubuntu

1. 22.04、24.04、26.04で、すぐに直す必要がある公開サーバーは、Canonicalの手順で、-proposedから入れられます。手順は、Canonicalの記事にあります。試験中の版なので、まず検証の環境で試し、入れたら、-proposedを有効にしたままにしないでください（これは、私の助言⁠で⁠す⁠）
2. 本番を、すぐには触れない場合は、上のnftablesの設定で、つな⁠ぎ⁠ま⁠す
3. 20.04以前は、修正待ちです。UbuntuのCVEのページを、定期的に確認してく⁠だ⁠さ⁠い

どのディストリビューショ⁠ン⁠で⁠も

• 更新だけでは足りません。再起動して、uname -rを確認します。ライブパッチを使っている場合は、その適用を確認⁠し⁠ま⁠す
• コンテナは、ホストのカーネルを使います。コンテナのイメージを更新しても、直り⁠ま⁠せ⁠ん
• 「MPTCPの待ち受けがないから大丈夫」とは、決めないでく⁠だ⁠さ⁠い

攻撃の探索は、始まってい⁠る⁠の⁠か

セキュリティ研究者のMarcus Hutchins氏が、11月3日に、Xで、次の観測を投稿しました（⁠X⁠）⁠。

• 11月2日から、住宅用プロキシと、ロシアのVPNサーバーが、ポート443に、MPTCPの接続で、探りを入れ⁠て⁠い⁠る
• 通常のスキャナーは、MPTCPを使わず、HTTPのデータも送られていない。このため、この欠陥を探している、と強く疑っている（氏の推測⁠で⁠す⁠）
• 10月30日の、インターネット全体の調査では、MPTCPで到達できるサーバーが、約210万台。ただし、これは、公開されている数で、カーネルが未修正の数で⁠は⁠な⁠い
• 公開された、遠隔からコードを実行する攻撃コードは、まだない。サービス拒否（DoS）の概念実証は、いくつか出回っ⁠て⁠い⁠る

この投稿は、攻撃が成功した、という報告ではありません。探りの観測と、氏の推測です。生のログや、侵害の痕跡の情報（IOC）は、投稿に添えられていません。ほかの観測組織による裏付けも、私が探した範囲では、見つかっていま⁠せ⁠ん⁠。

一方で、ほかの発表は、まだ、攻撃の報告をしていません。Akamaiは、「公開された、動く攻撃コードは、把握していない」としています（Akamai）。CISAのKEVにも、登録はありません（2026年11月4日の版を、直接確⁠認⁠）⁠。

読み方としては、こうです。探りの観測は、一人の研究者の、推測つきの報告です。ただ、修正版が、まだ通常の更新に出ていないUbuntuなどでは、「まだ攻撃が確認されていないから、あとでよい」とは、言いにくい状況です。公開しているサーバーは、上の対処を、先に進めてくだ⁠さ⁠い⁠。

未確⁠認⁠の⁠点

• Hutchins氏が観測した探りが、この欠陥を狙ったものかどうか。氏の推測で、ほかの組織の裏付けは、見つかってい⁠ま⁠せ⁠ん
• Anthropicの攻撃コードは、公開されていません。Akamaiも「公開された、動く攻撃コードは、把握していない」と書いています（Akam⁠a⁠i⁠）
• RHEL 9の勧告の、後半の部分（各系統の細かいパッケージ）は、読めていません。RHEL 8、10の勧告の、全体も、先頭の部分だけの確⁠認⁠で⁠す
• Red Hatの深刻度が、勧告ごとにそろっていな⁠い⁠理⁠由
• Red Hatのセキュリティ速報の本文が「修正を急いでいる」のままであ⁠る⁠理⁠由
• AlmaLinux、Rocky Linux、Oracle Linuxなど、RHEL互換の各社の、修⁠正⁠状⁠況
• Ubuntuの、通常の更新に移⁠る⁠時⁠期

関⁠連⁠記⁠事

• Linuxカーネルの深刻度9.8の欠陥――AIが実証した攻撃の条件と、ディストリビューションごとの修正状況：10月30日の記事。欠陥の仕組みと、Anthropicの実証が何を示⁠し⁠た⁠か
• PHP2Shellの報道と、一次情報で、合っていなかった点：見出しの数字が、一次情報とどう違ったか。数字の⁠読⁠み⁠方
• GitLabの深刻な欠陥は、2件ある――10月12日の修正版では足りない理由と、確認すること：同じ週の、GitLabの深刻度10.0の欠陥。直ったはずなのに、直っていない場合があ⁠り⁠ま⁠す
• 不正アクセスが相次ぐ今、経営者が先に決めておくこと――ゼロトラストとAI時代のセキュリティ対策：不正アクセスが相次ぐ今の、経営者向けの⁠考⁠え⁠方
• OpenSSHの脆弱性「*sshole」――対象は、AlpineなどのLinuxだけ。確認の方法と対処：同じ週の、OpenSSHの欠陥。musl libcのLinuxだけ⁠が⁠対⁠象

自社のサーバーの、カーネルの確認や、更新、再起動の計画でお困りの方は、お問い合わせくだ⁠さ⁠い⁠。