CVE-2025-38248

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bridge: mcast: Fix use-after-free during router port configuration<br /> <br /> The bridge maintains a global list of ports behind which a multicast<br /> router resides. The list is consulted during forwarding to ensure<br /> multicast packets are forwarded to these ports even if the ports are not<br /> member in the matching MDB entry.<br /> <br /> When per-VLAN multicast snooping is enabled, the per-port multicast<br /> context is disabled on each port and the port is removed from the global<br /> router port list:<br /> <br /> # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1<br /> # ip link add name dummy1 up master br1 type dummy<br /> # ip link set dev dummy1 type bridge_slave mcast_router 2<br /> $ bridge -d mdb show | grep router<br /> router ports on br1: dummy1<br /> # ip link set dev br1 type bridge mcast_vlan_snooping 1<br /> $ bridge -d mdb show | grep router<br /> <br /> However, the port can be re-added to the global list even when per-VLAN<br /> multicast snooping is enabled:<br /> <br /> # ip link set dev dummy1 type bridge_slave mcast_router 0<br /> # ip link set dev dummy1 type bridge_slave mcast_router 2<br /> $ bridge -d mdb show | grep router<br /> router ports on br1: dummy1<br /> <br /> Since commit 4b30ae9adb04 ("net: bridge: mcast: re-implement<br /> br_multicast_{enable, disable}_port functions"), when per-VLAN multicast<br /> snooping is enabled, multicast disablement on a port will disable the<br /> per-{port, VLAN} multicast contexts and not the per-port one. As a<br /> result, a port will remain in the global router port list even after it<br /> is deleted. This will lead to a use-after-free [1] when the list is<br /> traversed (when adding a new port to the list, for example):<br /> <br /> # ip link del dev dummy1<br /> # ip link add name dummy2 up master br1 type dummy<br /> # ip link set dev dummy2 type bridge_slave mcast_router 2<br /> <br /> Similarly, stale entries can also be found in the per-VLAN router port<br /> list. When per-VLAN multicast snooping is disabled, the per-{port, VLAN}<br /> contexts are disabled on each port and the port is removed from the<br /> per-VLAN router port list:<br /> <br /> # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1<br /> # ip link add name dummy1 up master br1 type dummy<br /> # bridge vlan add vid 2 dev dummy1<br /> # bridge vlan global set vid 2 dev br1 mcast_snooping 1<br /> # bridge vlan set vid 2 dev dummy1 mcast_router 2<br /> $ bridge vlan global show dev br1 vid 2 | grep router<br /> router ports: dummy1<br /> # ip link set dev br1 type bridge mcast_vlan_snooping 0<br /> $ bridge vlan global show dev br1 vid 2 | grep router<br /> <br /> However, the port can be re-added to the per-VLAN list even when<br /> per-VLAN multicast snooping is disabled:<br /> <br /> # bridge vlan set vid 2 dev dummy1 mcast_router 0<br /> # bridge vlan set vid 2 dev dummy1 mcast_router 2<br /> $ bridge vlan global show dev br1 vid 2 | grep router<br /> router ports: dummy1<br /> <br /> When the VLAN is deleted from the port, the per-{port, VLAN} multicast<br /> context will not be disabled since multicast snooping is not enabled<br /> on the VLAN. As a result, the port will remain in the per-VLAN router<br /> port list even after it is no longer member in the VLAN. This will lead<br /> to a use-after-free [2] when the list is traversed (when adding a new<br /> port to the list, for example):<br /> <br /> # ip link add name dummy2 up master br1 type dummy<br /> # bridge vlan add vid 2 dev dummy2<br /> # bridge vlan del vid 2 dev dummy1<br /> # bridge vlan set vid 2 dev dummy2 mcast_router 2<br /> <br /> Fix these issues by removing the port from the relevant (global or<br /> per-VLAN) router port list in br_multicast_port_ctx_deinit(). The<br /> function is invoked during port deletion with the per-port multicast<br /> context and during VLAN deletion with the per-{port, VLAN} multicast<br /> context.<br /> <br /> Note that deleting the multicast router timer is not enough as it only<br /> takes care of the temporary multicast router states (1 or 3) and not the<br /> permanent one (2).<br /> <br /> [1]<br /> BUG: KASAN: slab-out-of-bounds in br_multicast_add_router.part.0+0x3f1/0x560<br /> Write of size 8 at addr ffff888004a67328 by task ip/384<br /> [...]<br /> Call Trace:<br /> <br /> dump_stack<br /> ---truncated---