CVE-2025-37921: vxlan: vnifilter: Fix unlocked deletion of default FDB entry
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/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0
[...]
RIP: 0010:vxlan_find_mac+0x17f/0x1a0
[...]
Call Trace:
<TASK>
__vxlan_fdb_delete+0xbe/0x560
vxlan_vni_delete_group+0x2ba/0x940
vxlan_vni_del.isra.0+0x15f/0x580
vxlan_process_vni_filter+0x38b/0x7b0
vxlan_vnifilter_process+0x3bb/0x510
rtnetlink_rcv_msg+0x2f7/0xb70
netlink_rcv_skb+0x131/0x360
netlink_unicast+0x426/0x710
netlink_sendmsg+0x75a/0xc20
__sock_sendmsg+0xc1/0x150
____sys_sendmsg+0x5aa/0x7b0
___sys_sendmsg+0xfc/0x180
__sys_sendmsg+0x121/0x1b0
do_syscall_64+0xbb/0x1d0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
Security readout for executives and security teams
Plain-English summary
A Linux VXLAN cleanup operation can remove a forwarding entry without the required lock when a VNI is deleted in vnifilter mode. This can trigger a kernel warning and indicates unsafe concurrent state handling. The supplied record rates it 7.8 high, but provides no evidence of remote or active exploitation.
Executive priority
Prioritize affected network infrastructure and virtualization hosts, but do not treat this as an internet-wide emergency based on current evidence. Patch through normal high-severity kernel maintenance, accelerating systems that permit delegated network administration or frequently change VXLAN VNIs.
Technical view
The flaw affects deletion of the default-remote FDB entry during VXLAN VNI removal in vnifilter mode. The kernel calls the deletion path without holding the FDB hash lock. Referenced stable changes acquire and release that lock around deletion. The supplied evidence demonstrates a lockdep warning, not a proven compromise or crash.
Likely exposure
Exposure is limited to affected Linux kernels using VXLAN vnifilter mode with a configured default remote, particularly where local users or services can modify VNI configuration. The CVSS vector describes local, low-privilege access, but the source bundle does not establish which real-world permission models make the operation reachable.
Exploitation context
CISA KEV status is false, and the supplied sources do not report active exploitation or a public weaponized exploit. Triggering requires a local VNI deletion under a specific VXLAN configuration. Although CVSS models high confidentiality, integrity, and availability impact, the provided technical evidence only confirms unsafe locking and a warning.
Researcher notes
The record attributes the issue to an original VXLAN vnifilter implementation and describes the repair as locking the FDB hash during deletion. No CWE is supplied. Exact vulnerable and fixed package boundaries remain distribution-dependent; repeated commit identifiers and unusual version entries in the bundle warrant validation against vendor advisories.
Mitigation direction
Upgrade to a vendor-supported kernel containing the applicable referenced stable fix.
Consult the Linux distribution's advisory to map fixed commits to packaged kernel versions.
Restrict authorization for creating, changing, or deleting VXLAN VNI configurations.
Avoid unnecessary VNI deletion operations on exposed systems until remediation is applied.
Validation and detection
Inventory Linux kernel builds on systems using VXLAN networking.
Identify VXLAN devices operating in vnifilter mode with configured default remotes.
Compare exact vendor kernel packages against vendor advisories and referenced stable fixes.
Review kernel logs for warnings involving vxlan_find_mac or VXLAN VNI deletion.
After updating, confirm the running kernel is the intended remediated build.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-37921 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
7Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.