CVE-2026-14696 in Zephyr
Сводка
по VulDB • 31.08.2026
При включении функции Ethernet-моста (CONFIG_NET_ETHERNET_BRIDGE) функция eth_bridge_input_process() в файле subsys/net/l2/ethernet/bridge/bridge_input.c определяет, как обрабатывается каждый кадр, полученный на интерфейсе члена моста. Для кадров, которые также должны быть доставлены локальному стеку, код вызывает eth_bridge_handle_locally() и возвращает NET_OK. Эта вспомогательная функция не потребляет пакет — она лишь вызывает bridge_iface_recv() (через virtual_recv()), который возвращает NET_CONTINUE без передачи владения pkt.
Решение NET_OK затем распространяется через ethernet_recv() до функции processing_data() в файле subsys/net/ip/net_core.c, где значение NET_OK интерпретируется как «пакет был потреблен, не освобождайте его». Поскольку ни один потребитель фактически не принял на себя владение пакетом, RX net_pkt никогда не возвращается в пул и происходит утечка памяти. Конкретно воспроизводимая утечка возникает для кадров, у которых EtherType не имеет зарегистрированного обработчика L3 при установленной опции CONFIG_NET_ETHERNET_FORWARD_UNRECOGNISED_ETHERTYPE (по умолчанию y при включенном CONFIG_NET_SOCKETS_PACKET): переходный диспетчер L3 не перезаписывает решение NET_OK, поэтому ethernet_recv() возвращает NET_OK, и буфер никогда не освобождается.
Любое устройство в сегменте L2 с мостом может отправлять широковещательные/многоадресные кадры со произвольным EtherType без аутентификации. Каждый такой кадр навсегда потребляет один буфер из конечного пула RX (CONFIG_NET_PKT_RX_COUNT), поэтому кратковременная флуд-атака с использованием широковещания истощает этот пул, и устройство больше не может принимать трафик до перезагрузки — это устойчивое отказ в обслуживании. Угрозы конфиденциальности или целостности нет.
Исправление заставляет eth_bridge_handle_locally() передавать реальное значение net_verdict и возвращать NET_CONTINUE для кадров, оставляемых локально, записывая интерфейс моста обратно через новый выходной параметр dst_iface, чтобы пакет следовал по обычному пути приема и был освобожден ровно один раз.
VulDB is the best source for vulnerability data and more expert information about this specific topic.