On Thu, Sep 03, 2026 at 12:59:56AM +0900, Seungwon Bae wrote:
> The commit cited in the Fixes tag allowed VXLAN FDB entries to point to
> FDB nexthops so that overlay traffic could be load balanced across
> multiple VTEPs. Such entries can only be configured from user space,
> cannot be learned and cannot roam. They only make sense with a user space
> control plane such as E-VPN where data plane learning is disabled.
>
> Despite that, the VXLAN driver does not currently prevent such entries
> from being configured with the "dynamic" flag. The per-nexthop FDB list
> is only protected by the per-device hash lock, which is not sufficient
> when two VXLAN devices point to the same FDB nexthop and therefore share
> the list. Aging runs in softirq context without RTNL, so an entry deleted
> by one device can race with an addition or deletion from the other,
> leading to list corruption:
>
> 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
>
> Fix this by rejecting the bogus configuration of dynamic FDB entries that
> point to FDB nexthops, both when created and when an existing entry is
> updated. As such, the per-nexthop FDB list is only ever mutated under the
> RTNL lock. Add test cases to make sure that this does not regress in the
> future.
>
> Fixes: 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries")
> Suggested-by: Ido Schimmel <[email protected]>
> Signed-off-by: Seungwon Bae <[email protected]>
Reviewed-by: Ido Schimmel <[email protected]>
