CVE-2026-14697 in Zephyr
要約
〜によって VulDB • 2026年08月31日
subsys/net/ip/ipv6_nbr.cのnet_ipv6_send_ns()関数は、Neighbor Solicitation（NS）のために送信用net_pktを割り当てます。未解決の隣接ノードに保留中のデータパケットがあり、かつそのノードのpending_queueがすでに空でない場合（すなわち、既に送信中のNSが存在する場合）、この関数はデータパケットを追加し、net_send_data()経由でNSを送信することも、net_pkt_unref()で解放することなく、早期に戻ります。新しく割り当てられたNS用net_pktおよびそれに付随するTXバッファはローカル変数によってのみ保持され、永久にリークします。これらはCONFIG_NET_PKT_TX_COUNT / CONFIG_NET_BUF_TX_COUNTのプールには戻りません。
このリークが発生する分岐は、通常のIPv6送信パス上に位置しています。net_if.cから呼び出されるnet_ipv6_prepare_for_send()関数は、ネクストホップがまだ隣接キャッシュに存在しないすべての送信用または転送用IPv6パケットに対してnet_ipv6_send_ns()を呼び出します。オンリンク（近傍）の攻撃者は、単一の存在しないオンリンク送信元アドレスをスプーフィングした要求パケット（例えばICMPv6 echo requestやUDPデータグラムなど）の一斉送信によってこれを決定論的に誘発できます。ノードは各リクエストに対して返信を生成し、最初の返信がNSをキューに追加します。その後、約3秒間のINCOMPLETE解決ウィンドウ中に送られるその後のすべての返信はリークする分岐を通り、1つのTXパケットを失います。ルーターとして構成され、攻撃者のトラフィックが存在しないオンリンクホストへ転送しているノードも同様にリークします。
リークされたパケットは回収されないため、CONFIG_NET_PKT_TX_COUNTのデフォルト値がわずか4（Ethernetの場合14）であるという事実と相まって、短時間の低レートの一斉送信でTXプールを枯渇させます。一度枯渇すると、ノードはいかなる送信用パケットも割り当てられなくなり、TCP/UDP、ARP/ND、またはいかなる返信さえも送信できなくなります。これにより、再起動するまで自己修復しない完全かつ永続的なネットワークサービス拒否（DoS）が発生します。修正では、早期リターン前にnet_pkt_unref(pkt)を使用して未送信のNSパケットを解放しています。
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.