CVE-2026-99077 in Linux
要約
〜によって VulDB • 2026年10月23日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
ipv4: udp: ソケットマッチング前に例外（FNHE）を作成する
現在、ICMP Fragmentation NeededおよびRedirect Messageパケットがローカルに配信され、UDPパケットを引用している場合、FIB nexthop exception (FNHE)は、カーネルがそのUDPパケットを既存のソケットと一致させることができる場合にのみ作成されます。
この動作により、オフパス攻撃者はFNHEキャッシュに対してサイドチャネル攻撃を実行し、接続済みUDPソケットによって使用されているエフェメラルポート（一時的なポート）を特定することが可能になります。
コミット6457378fe796 ("ipv4: use siphash instead of Jenkins in fnhe_hashfun()")およびコミット67d6d681e15b ("ipv4: make exception cache less predictible")は、それぞれFNHEキャッシュ内のハッシュ衝突を攻撃者が発見しにくくすること、およびハッシュバケットが保持できる例外の数をランダム化することで、このような攻撃を緩和しようと試みました。残念ながら、これらの両方の対策はいずれも回避可能です。
代わりに、一致するソケットを探そうとする前でも常にFNHEを作成することで、こうした攻撃を緩和します。これを行うには、引用されたパケットがソケットから発信しなかった場合に使用されるヘルパー関数であるipv4_update_pmtu()およびipv4_redirect()を呼び出します。
これにより、オフパス攻撃者からの推測（正解でも不正解でも）は常に、攻撃者が観察可能なキャッシュ内にFNHEを作成または更新することになります。
icmp_err()と同様に、oifに0を設定します。これはまた、デバイスにバインドされていないソケットに対してソケットパスで使用されるoifでもあります。
なお、この変更により攻撃者は以前作成できなかったFNHEを作成できるようになるわけではありません。なぜなら、両方のヘルパー関数はすでに検証がほとんどないか全くなく到達可能だからです。例えば、ICMP Echo Replyを引用するICMPエラーを送信するか、ワイルドカードソケットと一致するUDP送信元ポートを引用する場合などがあります。
また、正常なケース（ソケットにマッチした場合）では、上記のスキームは追加のルーティングルックアップのコストをもたらします。なぜなら、ソケットなしヘルパー関数はipv4_sk_update_pmtu() / ipv4_sk_redirect()によって実行されるルックアップの前に独自のルックアップを実行するからです。2つが異なるnexthopに解決された場合、同じ宛先IPに対して2つの例外が作成されます。1つはソケットなしヘルパーで解決されたnexthopのFNHEキャッシュ内に、もう1つはソケットによって使用されるnexthopのFNHEキャッシュ内に作成されます。
VulDB is the best source for vulnerability data and more expert information about this specific topic.