CVE-2026-98432 の暫定対策を一次情報とソースで確かめた。IP オプションの遮断は効くが、それだけでは閉じない経路が 3 つある

Last updated at 2026-10-31Posted at 2026-10-31

Linux カーネルの CVE-2026-98432 は、認証なしでネットワークから届く IPv4 TCP の処理の use-after-free です。修正済みカーネルへの更新が根本対策ですが、ディストリビューションによってはまだ修正版が出ていません。

この記事では、カーネルを更新するまでの暫定対策を、CVE の記録、修正コミット、各ディストリビューションの情報、Linux v7.0 のソースで確かめました。フィルタのルールは手元の VM で実際に試しています。サーバーやコンテナホストを運用していて、更新までの間に何をすればよいかを知りたい人に向けた記事です。

確認したのは 2026 年 10 月 31 日 21 時ごろです。各社の状況は日々変わるので、使う前に出典のリンク先を見てください。

結論

一番の対策は修正済みカーネルへの更新と再起動です。CVE の記録、Red Hat、Go チームのどれもがそう書いています
更新までの間は、IPv4 オプション付きの TCP を落とすパケットフィルタが有効です。Red Hat も 10 月 30 日の公式ブリテンで同じ趣旨の nftables のルールを出しました。ただし Red Hat 自身が「完全には防げない」と書いています
フィルタだけでは閉じない経路が 3 つあります。ルールを入れる前に作られた要求ソケット、BPF による要求ソケットの移行、NetLabel の CIPSO です。どれも修正コミットの説明か v7.0 のソースで確認できます
MPTCP の無効化は、公表された攻撃の前提を外すだけです。元の use-after-free は残ります

2026 年 10 月 31 日時点の状況

項目	内容	出典
公開日	2026-10-15。Linux カーネルの CVE チームが採番	CVE の記録
原因	IPv4 TCP の接続処理で、受信した IP オプションを保持する `ireq_opt` と `inet_opt` が RCU の猶予期間を待たずに `kfree()` される	修正コミット
影響範囲	4.4 以降。原因は `079096f103fa` と、要求ソケット移行を入れた `c905dee62232`	修正コミット
修正版	5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10、7.3 以降	CVE の記録
修正の中身	`inet_sock_destruct()` と `tcp_v4_reqsk_destructor()` の `kfree()` を `kfree_rcu()` に変える 2 行	修正コミット
IPv6	本体の問題は受けない。CALIPSO を使うときの移行の問題は別の修正で扱う	修正コミット
実証	Anthropic が MPTCP で待ち受けるサーバーに対し、認証なしで root のコマンド実行まで到達。カーネルのポインタを漏らすまで 48 分、そこからさらに 5 分	Anthropic
CISA KEV	未掲載。10 月 30 日版で確認	KEV

深刻度は評価する組織で分かれています。

評価者	CVSS 3.1	区分
Linux カーネルの CNA	9.8	Critical
Red Hat	9.8	Critical
Amazon Linux	8.1 で AC:H	Important
SUSE	8.1	Important

ディストリビューションの状況です。

ディストリビューション	状況
Debian 12 / 13	修正済み。6.1.190-1、6.12.113-1、6.12.113-1~deb12u1
Amazon Linux 2023	修正済み。kernel、kernel6.12、kernel6.18
Amazon Linux 2	修正済み。kernel と 5.4 / 5.10 / 5.15 の Extra
Ubuntu 22.04 / 24.04 / 26.04	pending。修正版は作られていて公開待ち
Ubuntu 20.04 以前	needed
RHEL 8 / 9 / 10、OpenShift	Affected。修正版は未公開
RHEL 6 / 7	Not affected
SUSE	SLES 16.0、SL Micro 6.2、Leap 16.0 は修正済み。SLES 15 SP7 などは作業中

暫定対策のフィルタ

Red Hat のブリテン RHSB-2026-016 に載っているルールです。

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

ip hdrlength は IPv4 ヘッダの IHL です。オプションがなければ 5 で、オプションがあると 6 以上になります。TCP のオプションは TCP ヘッダに入るので、MSS や SACK などの普通の通信は落ちません。

同じ条件を input ではなく prerouting のフックに置くこともできます。

cve-2026-98432-prerouting.nft

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

	input	prerouting
対象	自分宛てのパケット	自分宛てと転送するパケット
向いている場所	サーバー	サーバーとルーター、Docker の bridge と NAT の経路

ルーターで内側のホストもまとめて守りたいなら prerouting が必要です。どちらのフックも tcp_v4_rcv() より前に評価されるので、サーバー単体ならどちらでも足ります。

iptables を使う場合は u32 で同じ条件を書けます。先頭 32 ビットを 24 ビット右にずらし、下位 4 ビットの IHL が 6 から 15 なら落とします。

sudo iptables -t raw -I PREROUTING 1 -p tcp -m u32 --u32 '0>>24&0x0F=0x06:0x0F' -j DROP

ルールを入れる前に、オプション付きの TCP が実際に来ているかを見ておくと、副作用を判断できます。

sudo tcpdump -ni any -c 100 'ip[0] & 0x0f > 5 and tcp'

手元で試した結果

3 つのルールが、オプション付きの SYN だけを落として普通の接続を通すかを試しました。攻撃コードは使っていません。

環境は Ubuntu 24.04.4、カーネル 6.8.0-117、nftables 1.0.9、iptables 1.8.10 の nf_tables 版です。VM の中に network namespace を 2 つ作って veth でつなぎ、片方で TCP の待ち受け、もう片方からクライアントで接続しました。オプション付きの SYN は、クライアントのソケットに IP_OPTIONS で Record Route を 8 バイト付けて作ります。

cli.py（抜粋）

s = socket.socket()
s.settimeout(3)
if sys.argv[1] == "opt":
    # Record Route: type 7, len 7, pointer 4, 空き 4 バイト + NOP
    s.setsockopt(socket.IPPROTO_IP, socket.IP_OPTIONS, bytes([7, 7, 4, 0, 0, 0, 0, 1]))
s.connect(("10.99.0.1", 8080))

ルール	普通の SYN	オプション付きの SYN	counter
なし	接続できた	接続できた
Red Hat の input / -310	接続できた	3 秒でタイムアウト	3 packets
prerouting / -310	接続できた	3 秒でタイムアウト	3 packets
iptables の u32 / raw PREROUTING	接続できた	3 秒でタイムアウト	3 packets

どのルールでも落ちたのはオプション付きの SYN だけでした。counter の 3 packets は、最初の SYN と 3 秒の間の再送 2 回です。ルールより前の prerouting -400 に置いた観測用の counter では、IHL が 5 より大きい SYN が届いていることも確かめました。

スクリプトと出力は samples/cve-2026-98432 に置いています。

1 行に詰めて書くと適用されない

最初は Red Hat のルールを 1 行に詰めて流し込み、適用されていないことに気づかずに試していました。nftables 1.0.9 では、ルールの後ろと、内側の } の後ろの両方に ; か改行が要ります。

末尾の書き方	`nft --check`
`counter drop } }`	syntax error
`counter drop; } }`	syntax error
`counter drop; }; }`	OK
`counter drop; }` と改行して `}`	OK

エラーになるとファイル全体が適用されません。スクリプトの中でエラーを見落とすと、守っているつもりで何も入っていない状態になります。Red Hat の手順どおり複数行で書き、nft --check を通してから適用し、nft list table inet cve_2026_98432 で counter の行があるかを確かめてください。

なお、この VM の Ubuntu 24.04 は net.mptcp.enabled が既定で 1 でした。待ち受けが MPTCP になるかはアプリしだいなので、ss -Mlnp で確かめます。

フィルタだけでは閉じない経路

1. ルールを入れる前に作られた要求ソケット

フィルタはこれから届くパケットにしか効きません。ルールを入れる前に、オプション付きの SYN で作られた要求ソケットは ireq_opt を持ったまま残ります。

しかも、競合の片側になる再送 SYN は、オプションが付いていなくても既存の要求ソケットの ireq_opt を読みます。オプションのない SYN はフィルタを通ります。

さらに、再送 SYN を受けるたびに要求ソケットのタイマーは延びます。v7.0 の net/ipv4/tcp_minisocks.c の tcp_check_req() です。

net/ipv4/tcp_minisocks.c（v7.0、765 行目から）

if (!tcp_rtx_synack(sk, req)) {
	unsigned long expires = jiffies;
	...
	expires += tcp_reqsk_timeout(req);
	if (!fastopen)
		mod_timer_pending(&req->rsk_timer,
				  expires);

SYNACK の再送上限を待てば消える、とは言い切れません。ルールを永続化してから再起動するのが確実です。再起動できないなら、待ち受けているサービスを止めて要求ソケットを捨て、それから起動し直します。

2. BPF による要求ソケットの移行

修正コミットは、要求ソケットの移行でも同じ問題が起きると書いています。条件は net.ipv4.tcp_migrate_req=1 か、BPF_SK_REUSEPORT_SELECT_OR_MIGRATE の BPF プログラムです。

tcp_migrate_req の既定値は 0 ですが、0 にしても BPF プログラムが移行を選べば経路は残ります。SO_REUSEPORT に BPF を付けて無停止で再起動するような構成は、sysctl だけで判断しないでください。

sysctl net.ipv4.tcp_migrate_req
sudo bpftool prog show | grep -i reuseport

この経路でも、移行される要求ソケットが ireq_opt を持つのはオプション付きの SYN を受けたときです。フィルタを入れたあとに新しく作られるものは対象になりません。

3. NetLabel の CIPSO

CIPSO を使う NetLabel の構成では、受信したパケットにオプションがなくても、カーネルが要求ソケットに IP オプションを付けます。v7.0 の cipso_v4_req_setattr() は、CIPSO のオプションを作って ireq_opt に入れます。

net/ipv4/cipso_ipv4.c（v7.0、抜粋）

opt = kzalloc(sizeof(*opt) + opt_len, GFP_ATOMIC);
...
req_inet = inet_rsk(req);
opt = unrcu_pointer(xchg(&req_inet->ireq_opt, RCU_INITIALIZER(opt)));

このホストではフィルタで ireq_opt の生成を止められません。SELinux の MLS などで CIPSO を使っているホストは、カーネル更新を先にしてください。

sudo netlabelctl -p map list

MPTCP の無効化について

Anthropic の実証は MPTCP の待ち受けを使っています。そのため MPTCP を止める案が出ていますが、Go のセキュリティチームは 10 月 29 日の告知でこう書いています。

While the demonstrated exploit requires the target system to expose an MPTCP listener, the underlying bug is not specific to MPTCP. It is possible that systems with no MPTCP listeners are vulnerable to similar attacks.

Go 1.24 以降の net パッケージは、Linux で待ち受けるときに既定で MPTCP を使います。止めるには GODEBUG=multipathtcp=0 を環境変数に入れるか、main モジュールの go.mod に godebug multipathtcp=0 を書きます。コードで ListenConfig.SetMultipathTCP(true) を呼んでいる場合は、こちらが優先されます。

sysctl net.mptcp.enabled
ss -Mlnp

Go チームは、プログラムごとの無効化は壊れやすい対策だとも書いています。一つでも MPTCP の待ち受けが残れば意味がなく、すべての攻撃が MPTCP を使うという前提にも立っているからです。フィルタと併用する追加の対策と考えるのがよいと思います。

古い情報と誤解しやすい点

公表から状況が変わったものと、よく見かける説明のうち一次情報と合わないものをまとめました。

よく見かける説明	一次情報で確認した内容
Red Hat は 5.9 のあと 8.1 Important	現在は 9.8 Critical。CVSS は draft の扱い
Red Hat は条件を満たす緩和策はないとしている	10 月 30 日の RHSB-2026-016 で nftables のルールを公開。完全には防げないと明記
Amazon Linux 2 は保留	10 月 30 日に修正済み
Ubuntu は作業中	22.04 / 24.04 / 26.04 は pending
`tcp_migrate_req=0` で移行経路も閉じる	BPF の移行は残る。修正コミットに明記
再送上限の約 63 秒を過ぎれば残った要求ソケットは消える	再送 SYN でタイマーが延びる。`tcp_check_req()`
RFC 7126 に沿ってオプション付きパケットを全面的に破棄するのが一般的	RFC 7126 はオプションごとの勧告。RR は既定で破棄、TS は破棄、CIPSO は既定では破棄しない、Quick-Start は既定で無視

パブリッククラウドの基盤側の影響は、各社の公開情報を確かめきれていないので、この記事では扱いません。

今日やること

uname -r で動いているカーネルを見て、各ディストリビューションのページと照らす
修正版があれば更新して再起動する
なければ IP オプション付き TCP を落とすルールを nft --check してから入れ、nft list table で counter の行があるか見る。ルーターでは prerouting を使う
ルールを永続化してから再起動する。できなければ待ち受けサービスを再起動する
SO_REUSEPORT の BPF と NetLabel の CIPSO を使っているホストを洗い出し、そこは更新を優先する
修正版が出たら更新して、ルールを消す

sudo nft delete table inet cve_2026_98432

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up