CVE-2026-80842: net: bridge: mcast: fix use-after-free of a master VLAN's multicast context
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: mcast: fix use-after-free of a master VLAN's multicast context
brmulticasttoggleonevlan() clears BRVLFLAGMCASTENABLED under br->multicastlock before stopping a VLAN's multicast context. That is the teardown handshake: lockless readers gate on the flag through brmulticastctxshoulduse() -> brmulticastctxvlandisabled(), so once it is cleared under the lock no reader can arm the context again.
For a master VLAN the handshake never runs. vlandel() clears BRIDGEVLANINFOBRENTRY before calling brvlanputmaster(), so brmulticasttoggleonevlan(masterv, false) returns early on !brvlanisbrentry(vlan): the flag stays set and br->multicastlock is never taken. brvlanputmaster() then drains the context in brmulticastctxdeinit() and frees the VLAN through callrcu(), while a reader still inside rcureadlock() sees the context as enabled and re-arms it. The port and port-VLAN branch of the function has no brvlanisbrentry() test and flips the flag under br->multicastlock, so it is not affected.
The reader is the bridge transmit path. For a master VLAN brmulticastrcv() selects brmctx = &vlan->brmcastctx with pmctx = NULL, so IGMP sent to the bridge device re-arms the context's timers after brmulticastctxdeinit() has already stopped them.
BUG: KASAN: slab-use-after-free in detachifpending+0x412/0x4a0 Write of size 8 at addr ffff88810ac39918 by task brmc/601 modtimer+0x51a/0xc50 brmulticasthostjoin+0x25b/0x390 brmulticastaddgroup+0x468/0x530 brip4multicastaddgroup+0x1a0/0x260 brmulticastrcv+0x2cda/0x61e0 brdevxmit+0x6c4/0x1540 Allocated by task 610: brvlanadd+0x111/0xb40 brvlaninfo+0x370/0x3e0 Freed by task 0: kfree+0x1a7/0x4f0 rcucore+0x7dc/0x10a0
Only test brvlanisbrentry() when enabling, like the brmulticastctxvlanglobaldisabled() test next to it. Disabling then always clears BRVLFLAGMCASTENABLED under br->multicastlock before brmulticastctxdeinit() drains the context.
Affected Software
Event History
Frequently Asked Questions
Which bridge VLAN configurations are affected?
The issue affects master VLANs whose multicast context is being torn down. The port and port-VLAN path is not affected because it clears the multicast-enabled flag while holding br->multicast_lock.
What race is required to trigger the use-after-free?
A bridge transmit-path reader must still be inside an RCU read-side critical section when a master VLAN is deleted. Because the multicast-enabled flag remains set during master-VLAN teardown, that reader can re-arm the multicast context after it has been drained and while the VLAN is being freed through call_rcu().