Linux カーネルの IPv4 オプション処理の UAF（CVE-2026-98432）：カーネル更新までは IP オプション付き TCP を落とす

IP オプションを含む IPv4 の TCP 接続要求で起きる競合状態の use-after-free。認証も操作も不要で、Red Hat は Critical（CVSS v3.1 9.8）と評価。修正カーネルを入れるまで、IP オプション付きの受信 IPv4 TCP を nftables で破棄する暫定策がある。

何が問題か

接続要求の再送やソケットの移行といった並行処理が参照している最中に、ソケットオプションが先に解放される。タイミングを合わせた通信で、停止・メモリー破壊・コード実行に至りうる。
既定構成でも TCP を受け付けるだけで遠隔から届く。MPTCP の有効化などの条件はない。安定したコード実行にはヒープの精密な制御が要るが、停止させるだけなら現実的と考えて優先度を上げる。

対応

修正カーネルがあるディストリビューションでは、まず更新して再起動する（RHEL 8〜10 の標準カーネル、RHEL 9.8 の kernel-rt などに修正版。RHEL CoreOS は 11 月 4 日時点で修正待ち）。
更新を待つ間は、IP オプションを含む受信 IPv4 TCP パケットを破棄するルールを入れる。通常の TCP オプションは TCP ヘッダー側にあるので、一般の通信には影響しにくい。IP オプションを使う特殊な通信がある環境では業務影響を先に確かめる。
ルールの形の例（Red Hat の公式ルールを優先すること。ここでは「IPv4 ヘッダー長が 20 バイトを超える＝IP オプションあり」の TCP を落とす考え方を示す）:
```
nft add table inet cve_2026_98432
nft add chain inet cve_2026_98432 input '{ type filter hook input priority -300; }'
nft add rule inet cve_2026_98432 input ip hdrlength gt 5 meta l4proto tcp drop
```
このルールは再起動で消える。カーネル更新より前に再起動したら入れ直すか、永続化する。

注意

パッチの代わりにはならない。攻撃にさらされる範囲を減らすだけ。
OpenShift などのノードでは、ホストのネットワーク名前空間を通る通信にしか効かない。Pod 間通信は対象外で、外部から Pod へ転送される通信が含まれるかは構成次第。クラスター手前の境界（ロードバランサーやファイアウォール）で落とせばこの制約はない。
OpenShift 4 では MachineConfig とノードの中断ポリシーで、不要な再起動を避けつつルールを配る暫定ガイダンスが出ている。ROSA・ARO・OSD は別ガイダンス。

出典

@MalwareBibleJP · 2026-11-05