CVE-2026-98023
Sumário
de VulDB • 25/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
vxlan: rejeitar entradas de FDB dinâmicas que referenciam um ID de nexthop
O commit citado na tag Fixes permitia que as entradas de VXLAN FDB apontassem para nexthops de FDB, permitindo o balanceamento de carga do tráfego overlay entre múltiplos VTEPs. Tais entradas só podem ser configuradas a partir do espaço do usuário (user space), não são aprendidas automaticamente e não suportam roaming. Elas fazem sentido apenas com um plano de controle no user space, como E-VPN, onde o aprendizado do data plane está desabilitado.
Apesar disso, o driver VXLAN atualmente não impede que essas entradas sejam configuradas com a flag "dynamic". A lista FDB por nexthop é protegida apenas pelo hash lock por dispositivo, o que não é suficiente quando dois dispositivos VXLAN apontam para o mesmo nexthop de FDB e, portanto, compartilham a mesma lista. O processo de expiração (aging) ocorre no contexto softirq sem RTNL; assim, uma entrada excluída por um dispositivo pode sofrer race condition com uma adição ou exclusão do outro, levando à corrupção da lista:
list_del corruption. next->prev should be ffff8881069d9548, but was dead000000000122. (next=ffff8881069d9448) WARNING: CPU: 0 PID: 90 at lib/list_debug.c:65 __list_del_entry_valid_or_report+0x1aa/0x210 ... vxlan_fdb_destroy+0x5b8/0xad0 vxlan_cleanup+0x328/0x450 call_timer_fn+0x2a/0x1c0 run_timer_softirq+0x18c/0x210 BUG: KASAN: slab-use-after-free in vxlan_fdb_destroy
Corrija isso rejeitando a configuração inválida de entradas FDB dinâmicas que apontam para nexthops de FDB, tanto na criação quanto quando uma entrada existente é atualizada. Dessa forma, a lista FDB por nexthop será modificada apenas sob o bloqueio RTNL. Adicione casos de teste para garantir que isso não cause regressões no futuro.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.