Linux カーネルの TCP の脆弱性（CVE-2026-98432）とは？対象の確認と更新、つなぎの対策

自社や自分の Linux サーバーを運用している方向けの記事です。「カーネルに深刻な TCP の脆弱性が出たらしい」と聞いて、自分のサーバーは対象か、いまできることは何かを確かめたい人が、そのまま作業できるようにまとめました。

この記事は、CVE レコード（kernel.org が採番、MITRE の API で確認）、Debian のセキュリティトラッカー、Ubuntu の CVE ページ、Red Hat のセキュリティ情報（RHSB-2026-016）、AlmaLinux と CIQ（Rocky Linux の提供元）の告知、oss-security への投稿、CISA の KEV をもとにしています（いずれも2026年11月1日に確認）。修正版の状況は日々変わるので、作業の前にお使いのディストリビューションの最新の案内を確かめてください。

何が起きたのか：再送された SYN と解放のすれ違い

TCP の接続を始めるとき、相手が最初に送るパケットを SYN と呼びます。この SYN に IP オプション（通常の通信ではほとんど使われない付加情報）が付いていると、カーネルは接続が完成するまでそのオプションを保持します。

CVE レコードによると、接続が完成するとき、カーネルはこのオプションをコピーせずに新しい接続へ引き渡します。そのため、相手が SYN を再送し、別の CPU がその応答（SYN-ACK）を作っている最中に、接続のほうが閉じられてオプションが解放されると、応答の処理が解放済みのメモリを読んでしまいます。これが use-after-free（解放後のメモリの利用）です。

自分のサーバーは対象か：条件と、修正の状況

対象は、カーネル 4.4 以降で、IPv4 の TCP ポートを外部のネットワークに向けて開いているサーバーです。Web サーバー、SSH、データベースなど、何であっても「接続を受ける側」であれば当てはまります。ディストリビューションの AlmaLinux は「信頼できないネットワークから IPv4 の TCP 接続を受けるシステムは、危険にさらされていると考える」と説明しています。

コンテナを使っている場合、コンテナはホストのカーネルを共有します。コンテナ側で何かを入れ替えても直らず、ホストのカーネルを更新して再起動する必要があります。

# 動いているカーネルの版（共通）
uname -r

# 待ち受けている IPv4 の TCP ポート（外部から届くものがあるか）
ss -ltn4

# RHEL 系：パッケージの変更履歴に、この CVE への言及があるか（修正が入っていれば表示される）
rpm -q --changelog kernel | grep CVE-2026-98432

# MPTCP が有効か（1 なら有効）
sysctl net.mptcp.enabled

修正の状況は、2026年11月1日の時点で次のとおりです。

更新の手順：修正が出ているものから、更新して再起動する

修正入りのカーネルが出ているディストリビューション（Debian など）では、パッケージを更新し、再起動します。更新しただけで再起動しないと、古いカーネルが動き続けます。

# Debian・Ubuntu：更新して再起動
sudo apt update && sudo apt upgrade
sudo reboot

# 再起動後に版を確かめる（Debian 12 なら 6.1.190-1 以降、Debian 13 なら 6.12.113-1 以降）
uname -v

# RHEL 系：修正が公開されたら
sudo dnf update kernel\*
sudo reboot

修正が出るまでのつなぎ：IP オプション付きの TCP を落とす

Red Hat、AlmaLinux、CIQ は、IP オプション付きの IPv4 の TCP パケットを、カーネルに届く前に落とす nftables のルールを案内しています。この脆弱性の入口が「IP オプション付きの SYN」なので、そこを塞ぐ考え方です。Red Hat の案内にあるルールは次のとおりです。

# cve-2026-98432.nft として保存
table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

# 構文を確かめてから適用し、入ったことを確認する
sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

# 修正入りのカーネルに更新したあと、ルールを消す
sudo nft delete table inet cve_2026_98432

MPTCP を使う必要がなければ、net.mptcp.enabled を 0 にし、ss -lnMp で MPTCP の待ち受けが無いことを確かめるのも、実証コードの経路を減らす補助になります。Go で作ったプログラムは、Go 1.24 から待ち受けで MPTCP が既定で有効になっているため、環境変数 GODEBUG=multipathtcp=0 で切ることもできます。ただし Go のチーム自身が「壊れやすい対策」と呼んでいて、1つでも MPTCP の待ち受けが残れば危険が残ります。

oss-security には、起動パラメータ init_on_free=1（解放時にメモリをゼロにする）を併用するという個人の提案もあります。読み出し内容が狭まるという考え方で、一般的な負荷は1〜5%とされています。ただしバグそのものは残り、公式の案内ではないので、あくまで補助として、自分の環境で性能を測ってから検討する位置づけです。

どれくらい急ぐか：評価が割れている点と、悪用の状況

「複雑さが高い」は、安全という意味ではありません。実証が報告され、Debian が修正を出し、Red Hat が Critical にしている以上、修正が出た時点で速やかに更新できる体制を整えておくのが現実的です。

手順のまとめ

参考にした情報

• CVE レコード：CVE-2026-98432（kernel.org が採番）
• Debian：セキュリティトラッカー
• Ubuntu：CVE ページ
• Red Hat：RHSB-2026-016、CVE ページ
• AlmaLinux：CVE-2026-98432 の告知
• CIQ：緩和策の案内
• oss-security：Go セキュリティチームの告知（10月29日）、init_on_free の提案（10月31日）

同じ週に更新が求められている話題は、Linux カーネルの権限昇格 Fragnesia（KEV 掲載済み）にまとめています。優先順位の考え方は KEV カタログの記事、年間の一覧は 2026年のセキュリティ更新の記録です。