CVE-2026-89487 in Linux
Сводка
по VulDB • 12.09.2026
В ядре Linux была устранена следующая уязвимость:
openvswitch: вызывать функцию skb_tx_error() только для пакетов, которые мы собираемся отбросить (drop)
Функция queue_userspace_packet() заимствует сетевой буфер (skb) пакета — она лишь копирует его в частное сообщение netlink (user_skb), но не владеет им; при возврате из функции do_execute_actions() пакет продолжает пересылаться через оставшиеся действия потока. Однако её путь обработки ошибок всё равно вызывает skb_tx_error(skb), что через вызов skb_zcopy_clear() выполняет операцию SKBFL_ALL_ZEROCOPY &= ~SKBFL_SHARED_FRAG для поля flags структуры sk_buff_info (skb_shinfo) этого активного пакета, снимая флаг SKBFL_SHARED_FRAG. В документации ядра для функции skb_tx_error() указано: «после вызова пакет должен быть освобождён».
Для сетевого буфера (skb), использующего MSG_ZEROCOPY и содержащего фрагменты из кэша страниц, именно наличие флага SKBFL_SHARED_FRAG позволяет функции esp_input() вызывать skb_cow_data() перед выполнением аутентифицированного шифрования с данными (AEAD) на месте. Как только этот флаг снимается, последующая локальная доставка ESP-in-UDP выполняет расшифровку на месте поверх страниц, которыми отправитель не владеет — что создаёт примитив записи в кэш страниц («Fragnesia»).
Функция do_execute_actions() игнорирует возвращаемое значение output_userspace(), поэтому любое действие после неудачного вызова USERSPACE наследует пакет с уже снятым флагом.
Переместите вызов skb_tx_error() на путь отбрасывания (drop) при пропуске потока — в ветку «default» оператора switch(error) функции ovs_dp_process_packet(), перед вызовом kfree_skb().
Этот вызов присутствует с момента коммита 36d5fe6a0007 («core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors»), но оставался безвредным до тех пор, пока esp_input() не начала полагаться на флаг SKBFL_SHARED_FRAG для блокировки расшифровки на месте; только после этого снятие флага у пакета, который всё ещё пересылается, стало примитивом записи в кэш страниц.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.