In the Linux kernel, the following vulnerability has been resolved:

bridge: mcast: Fix use-after-free during router port configuration

The bridge maintains a global list of ports behind which a multicast router resides. The list is consulted during forwarding to ensure multicast packets are forwarded to these ports even if the ports are not member in the matching MDB entry.

When per-VLAN multicast snooping is enabled, the per-port multicast context is disabled on each port and the port is removed from the global router port list:

ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1

ip link add name dummy1 up master br1 type dummy

ip link set dev dummy1 type bridge_slave mcast_router 2

$ bridge -d mdb show | grep router router ports on br1: dummy1

ip link set dev br1 type bridge mcast_vlan_snooping 1

$ bridge -d mdb show | grep router

However, the port can be re-added to the global list even when per-VLAN multicast snooping is enabled:

ip link set dev dummy1 type bridge_slave mcast_router 0

ip link set dev dummy1 type bridge_slave mcast_router 2

$ bridge -d mdb show | grep router router ports on br1: dummy1

Since commit 4b30ae9adb04 ("net: bridge: mcast: re-implement br_multicast_{enable, disable}_port functions"), when per-VLAN multicast snooping is enabled, multicast disablement on a port will disable the per-{port, VLAN} multicast contexts and not the per-port one. As a result, a port will remain in the global router port list even after it is deleted. This will lead to a use-after-free [1] when the list is traversed (when adding a new port to the list, for example):

ip link del dev dummy1

ip link add name dummy2 up master br1 type dummy

ip link set dev dummy2 type bridge_slave mcast_router 2

Similarly, stale entries can also be found in the per-VLAN router port list. When per-VLAN multicast snooping is disabled, the per-{port, VLAN} contexts are disabled on each port and the port is removed from the...