Skip to content
Heist/ feed
Back to feed
UnratedFix available

net: dsa: clean up FDB, MDB, VLAN entries on unbind

Type: advisorySources: OSV

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 source

Published 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"
}