In the Linux kernel, the following vulnerability has been resolved:
vxlan: vnifilter: Fix unlocked deletion of default FDB entry
When a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB entry associated with the default remote (assuming one was configured) is deleted without holding the hash lock. This is wrong and will result in a warning [1] being generated by the lockdep annotation that was added by commit ebe642067455 ("vxlan: Create wrappers for FDB lookup").
Reproducer:
# ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0 # bridge vni del vni 10010 dev vx0
Fix by acquiring the hash lock before the deletion and releasing it afterwards. Blame the original commit that introduced the issue rather than the one that exposed it.
[1] WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlancore.c:417 vxlanfindmac+0x17f/0x1a0 [...] RIP: 0010:vxlanfindmac+0x17f/0x1a0 [...] Call Trace: <TASK> vxlanfdbdelete+0xbe/0x560 vxlanvnideletegroup+0x2ba/0x940 vxlanvnidel.isra.0+0x15f/0x580 vxlanprocessvnifilter+0x38b/0x7b0 vxlanvnifilterprocess+0x3bb/0x510 rtnetlinkrcvmsg+0x2f7/0xb70 netlinkrcvskb+0x131/0x360 netlinkunicast+0x426/0x710 netlinksendmsg+0x75a/0xc20 _socksendmsg+0xc1/0x150 _syssendmsg+0x5aa/0x7b0 _syssendmsg+0xfc/0x180 _syssendmsg+0x121/0x1b0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x4b/0x53