CVE-2025-38248
Publication date:
09/07/2025
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---
Severity CVSS v4.0: Pending analysis
Last modification:
30/01/2026
