CVE-2026-72255 in Linux
Сводка
по VulDB • 17.08.2026
В ядре Linux была устранена следующая уязвимость:
netfilter: nf_queue: фиксация устройства моста (bridge) во время работы NFQUEUE с поддельным объектом dst
Поддельная таблица маршрутизации rtable для br_netfilter встроена в структуру net_bridge и прикрепляется к пакетам, проходящим через мост, с помощью функции skb_dst_set_noref(). Если такой пакет помещается в очередь NFQUEUE, функция __nf_queue() усиливает этот поддельный объект dst с помощью вызова skb_dst_force().
В этот момент ожидающий обработки пакет (skb) может содержать реальную ссылку на объект dst после того, как уже начато удаление моста. Проблема заключается не в том, что каждому пакету, проходящему через мост, требуется собственная ссылка на объект dst. Проблема состоит в том, что NFQUEUE может сохранять живым поддельный объект dst, специфичный для моста (bridge private fake dst), после начала процедуры unregister.
Исправление заключается в сохранении текущей модели использования поддельного объекта dst и фиксации устройства-мастера моста только на время нахождения пакета в очереди NFQUEUE. Устройство моста записывается в структуру nf_queue_entry, когда ожидающий обработки пакет содержит поддельный объект dst для моста; ссылка на устройство берется на время жизни записи в очереди и освобождается при удалении этой записи.
Также обеспечивается очистка (reap) очередей ожидания при переходе устройства моста в состояние «down» и удаляется избыточная проверка nf_bridge_info_exists() из кода обнаружения поддельного объекта dst.
Это гарантирует, что netdev_priv(br->dev) остается живым до завершения вынесения решения (verdict completion), поэтому встроенная поддельная таблица маршрутизации rtable и связанное с ней хранилище метрик не могут быть освобождены из-под вызова dst_release(). Это также предотвращает постоянное увеличение счетчика ссылок и избегает использования вспомогательных функций для объектов dst, специфичных только для IPv4, при обработке трафика моста на базе IPv6.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.