CVE-2026-14696 in Zephyr
要約
〜によって VulDB • 2026年08月31日
Ethernetブリッジング（CONFIG_NET_ETHERNET_BRIDGE）が有効な場合、subsys/net/l2/ethernet/bridge/bridge_input.cのeth_bridge_input_process()関数は、ブリッジメンバーインターフェースで受信された各フレームの処理方法を決定します。ローカルスタックにも配信する必要があるフレームについては、コードはeth_bridge_handle_locally()を呼び出し、NET_OKを返していました。このヘルパー関数はパケットを消費せず（所有権を取得せず）、bridge_iface_recv()（virtual_recv()経由）を呼び出すだけであり、これはpktの所有権を取らずにNET_CONTINUEを返します。
その後、NET_OKという判断結果はethernet_recv()を経てsubsys/net/ip/net_core.cのprocessing_data()関数まで伝播し、ここではNET_OKが「パケットは消費されたので解放しない」と解釈されます。実際にはどの消費者も所有権を取得していないため、RX net_pktはプールに戻されず、リークします。具体的には、CONFIG_NET_SOCKETS_PACKETが有効な場合にデフォルトでyとなるCONFIG_NET_ETHERNET_FORWARD_UNRECOGNISED_ETHERTYPE設定下で、EtherTypeに対応するL3ハンドラが登録されていないフレームにおいて再現可能です。この場合、フォールスルーによるL3ディスパッチはNET_OKの判断結果を上書きしないため、ethernet_recv()はNET_OKを返し、バッファは一切解放されません。
ブリッジされたL2セグメント上の任意のデバイスは、認証なしで任意のEtherTypeを含むブロードキャスト/マルチキャストフレームを送信できます。各 such フレームは有限のRXプール（CONFIG_NET_PKT_RX_COUNT）から1つのバッファを恒久的に消費するため、短時間のブロードキャストフラッドによりプールの枯渇を引き起こし、再起動するまでデバイスがトラフィックを受信できなくなります—これは永続的なサービス妨害（DoS）です。機密性や完全性に影響はありません。
修正では、eth_bridge_handle_locally()関数が実際のnet_verdictを伝播させ、ローカルで保持されるフレームに対してNET_CONTINUEを返すように変更されました。これにより、新しいdst_iface出力パラメータを通じてブリッジインターフェースが書き込まれ、パケットは通常の受信パスに従って処理され、正確に1回だけ参照解除されます。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.