CVE-2025-37864

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: clean up FDB, MDB, VLAN entries on unbind<br /> <br /> As explained in many places such as commit b117e1e8a86d ("net: dsa:<br /> delete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written given<br /> the assumption that higher layers have balanced additions/deletions.<br /> As such, it only makes sense to be extremely vocal when those<br /> assumptions are violated and the driver unbinds with entries still<br /> present.<br /> <br /> But Ido Schimmel points out a very simple situation where that is wrong:<br /> https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/<br /> (also briefly discussed by me in the aforementioned commit).<br /> <br /> Basically, while the bridge bypass operations are not something that DSA<br /> explicitly documents, and for the majority of DSA drivers this API<br /> simply causes them to go to promiscuous mode, that isn&amp;#39;t the case for<br /> all drivers. Some have the necessary requirements for bridge bypass<br /> operations to do something useful - see dsa_switch_supports_uc_filtering().<br /> <br /> Although in tools/testing/selftests/net/forwarding/local_termination.sh,<br /> we made an effort to popularize better mechanisms to manage address<br /> filters on DSA interfaces from user space - namely macvlan for unicast,<br /> and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the<br /> fact is that &amp;#39;bridge fdb add ... self static local&amp;#39; also exists as<br /> kernel UAPI, and might be useful to someone, even if only for a quick<br /> hack.<br /> <br /> It seems counter-productive to block that path by implementing shim<br /> .ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPP<br /> in order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() from<br /> running, although we could do that.<br /> <br /> Accepting that cleanup is necessary seems to be the only option.<br /> Especially since we appear to be coming back at this from a different<br /> angle as well. Russell King is noticing that the WARN_ON() triggers even<br /> for VLANs:<br /> https://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/<br /> <br /> What happens in the bug report above is that dsa_port_do_vlan_del() fails,<br /> then the VLAN entry lingers on, and then we warn on unbind and leak it.<br /> <br /> This is not a straight revert of the blamed commit, but we now add an<br /> informational print to the kernel log (to still have a way to see<br /> that bugs exist), and some extra comments gathered from past years&amp;#39;<br /> experience, to justify the logic.