net: dsa: clean up FDB, MDB, VLAN entries on unbind
In the Linux kernel, the following vulnerability has been resolved: net: dsa: clean up FDB, MDB, VLAN entries on unbind As explained in many places such as commit b117e1e8a86d ("net: dsa: delete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written given the assumption that higher layers have balanced additions/deletions. As such, it only makes sense to be extremely vocal when those assumptions are violated and the driver unbinds with entries still present. But Ido Schimmel points out a very simple situation where that is wrong: https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/ (also briefly discussed by me in the aforementioned commit). Basically, while the bridge bypass operations are not something that DSA explicitly documents, and for the majority of DSA drivers this API simply causes them to go to promiscuous mode, that isn't the case for all drivers. Some have the necessary requirements for bridge bypass operations to do something useful - see dsa_switch_supports_uc_filtering(). Although in tools/testing/selftests/net/forwarding/local_termination.sh, we made an effort to popularize better mechanisms to manage address filters on DSA interfaces from user space - namely macvlan for unicast, and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the fact is that 'bridge fdb add ... self static local' also exists as kernel UAPI, and might be useful to someone, even if only for a quick hack. It seems counter-productive to block that path by implemen
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.1.175, 6.12.25, 6.14.4, 6.6.88
- CVEs
- CVE-2025-37864
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 15:24 UTC · Revision 1
Source evidence
net: dsa: clean up FDB, MDB, VLAN entries on unbind
core-osv · Original sourcePublished 9 May 2025, 06:43 UTC
In the Linux kernel, the following vulnerability has been resolved: net: dsa: clean up FDB, MDB, VLAN entries on unbind As explained in many places such as commit b117e1e8a86d ("net: dsa: delete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written given the assumption that higher layers have balanced additions/deletions. As such, it only makes sense to be extremely vocal when those assumptions are violated and the driver unbinds with entries still present. But Ido Schimmel points out a very simple situation where that is wrong: https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/ (also briefly discussed by me in the aforementioned commit). Basically, while the bridge bypass operations are not something that DSA explicitly documents, and for the majority of DSA drivers this API simply causes them to go to promiscuous mode, that isn't the case for all drivers. Some have the necessary requirements for bridge bypass operations to do something useful - see dsa_switch_supports_uc_filtering(). Although in tools/testing/selftests/net/forwarding/local_termination.sh, we made an effort to popularize better mechanisms to manage address filters on DSA interfaces from user space - namely macvlan for unicast, and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the fact is that 'bridge fdb add ... self static local' also exists as kernel UAPI, and might be useful to someone, even if only for a quick hack. It seems counter-productive to block that path by implemen
osv:CVE-2025-37864
Kernel
Fixed versions: 6.1.175, 6.6.88, 6.12.25, 6.14.4
Complete source record
{
"id": "08858b9d9d59d09ccc9604dbf461256232de03890245b7ddc588c12f1ac83e5e",
"url": "https://osv.dev/vulnerability/CVE-2025-37864",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "net: dsa: clean up FDB, MDB, VLAN entries on unbind",
"summary": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: clean up FDB, MDB, VLAN entries on unbind As explained in many places such as commit b117e1e8a86d (\"net: dsa: delete dsa_legacy_fdb_add and dsa_legacy_fdb_del\"), DSA is written given the assumption that higher layers have balanced additions/deletions. As such, it only makes sense to be extremely vocal when those assumptions are violated and the driver unbinds with entries still present. But Ido Schimmel points out a very simple situation where that is wrong: https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/ (also briefly discussed by me in the aforementioned commit). Basically, while the bridge bypass operations are not something that DSA explicitly documents, and for the majority of DSA drivers this API simply causes them to go to promiscuous mode, that isn't the case for all drivers. Some have the necessary requirements for bridge bypass operations to do something useful - see dsa_switch_supports_uc_filtering(). Although in tools/testing/selftests/net/forwarding/local_termination.sh, we made an effort to popularize better mechanisms to manage address filters on DSA interfaces from user space - namely macvlan for unicast, and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the fact is that 'bridge fdb add ... self static local' also exists as kernel UAPI, and might be useful to someone, even if only for a quick hack. It seems counter-productive to block that path by implemen",
"evidence": "osv:CVE-2025-37864",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.1.175",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.88",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.25",
"evidence": "/affected/1/ranges"
},
{
"value": "6.14.4",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2025-37864",
"aliases": [
"CVE-2025-37864"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "0832cd9f1f023226527e95002d537123061ddac4"
},
{
"fixed": "5e531e71b9d21d5e985251440e0d722f71299b7a"
},
{
"fixed": "86c6613a69bca815f1865ed8cedfd4b9142621ab"
},
{
"fixed": "8fcc1e6f808912977caf17366c625b95dc29ba4f"
},
{
"fixed": "99c50c98803425378e08a7394dc885506dc85f06"
},
{
"fixed": "7afb5fb42d4950f33af2732b8147c552659f79b7"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-37864.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.18.0"
},
{
"fixed": "6.1.175"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.88"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.25"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.14.4"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-37864.json"
}
}
],
"modified": "2026-10-28T02:30:36.789531324Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/5e531e71b9d21d5e985251440e0d722f71299b7a",
"https://git.kernel.org/stable/c/7afb5fb42d4950f33af2732b8147c552659f79b7",
"https://git.kernel.org/stable/c/86c6613a69bca815f1865ed8cedfd4b9142621ab",
"https://git.kernel.org/stable/c/8fcc1e6f808912977caf17366c625b95dc29ba4f",
"https://git.kernel.org/stable/c/99c50c98803425378e08a7394dc885506dc85f06",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/37xxx/CVE-2025-37864.json",
"https://nvd.nist.gov/vuln/detail/CVE-2025-37864",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/37xxx/CVE-2025-37864.json"
}
},
"related_cves": [
{
"value": "CVE-2025-37864",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 504095,
"published_at": "2025-05-09T06:43:54.873+00:00"
}