CVE-2026-99076 in Linux
要約
〜によって VulDB • 2026年10月24日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
ipv6: udp: ソケットマッチング前に例外を作成する
現在、ICMPv6 Packet Too Big および Redirect Message パケットがローカルに配信され、UDP パケットを引用している場合、IPv6 例外キャッシュへの例外の作成は、カーネルが UDP パケットを既存のソケットと一致させることができる場合にのみ行われます。
この動作により、オフパス攻撃者は例外キャッシュに対するサイドチャネル攻撃を実行し、接続済み UDP ソケットによって使用されているエフェメラルポート（一時的なポート）を発見することが可能になります。
コミット 4785305c05b2 ("ipv6: use siphash in rt6_exception_hash()") およびコミット a00df2caffed ("ipv6: make exception cache less predictible") は、それぞれ例外キャッシュ内のハッシュ衝突を攻撃者が発見しにくくすること、およびハッシュバケットが保持できる例外の数をランダム化することで、このような攻撃を緩和しようと試みました。残念ながら、これらの両方の対策は回避可能です。
代わりに、一致するソケットを見つけようとする前であっても常に例外を作成することで、こうした攻撃を緩和します。これを行うには、引用されたパケットがソケットから発信されなかった場合に使用されるヘルパー関数である ip6_update_pmtu() および ip6_redirect() を呼び出します。
つまり、オフパス攻撃者からの推測（正解でも不正解でも）は、常にキャッシュ内に例外を作成または更新し、その結果を攻撃者が観測可能になります。
icmpv6_err() と同様の方法で、受信デバイスの ifindex およびデフォルトの uid を渡します。IPv4とは異なり、oif が 0 の場合、ip6_redirect_nh_match() で一致するnexthopが存在せず、Redirect Message に対する例外は作成されません。
なお、この変更により攻撃者が以前には作成できなかった例外を作成できるわけではありません。なぜなら、両方のヘルパー関数はすでに検証がほとんどないか全くなくして到達可能だからです。例えば、ICMPv6 Echo Reply を引用する ICMPv6 エラーを送信するか、ワイルドカードソケットと一致する UDP ソースポートを引用する場合などがあります。
また、正常なケース（ソケットにマッチした場合）では、上記のスキームは ip6_sk_update_pmtu() / ip6_sk_redirect() によって行われるルックアップの前に、no socket ヘルパーが独自のルックアップを行うため、追加のルート検索のコストがかかります。2つのnexthopが異なる結果になった場合、同じ宛先IPに対して例外が2つ作成されることになります。1つは no socket ヘルパーで解決された nexthop の例外キャッシュに、もう1つはソケットによって使用される nexthop の例外キャッシュにそれぞれ作成されます。
If you want to get best quality of vulnerability data, you may have to visit VulDB.