Cloudanix VulnDB

CVE-2026-80842

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in Linux network bridging can let attackers crash or potentially take over systems by sending certain network packets that confuse how the kernel cleans up internal structures.

Exploitation
Adjacent Network
Attacker needs
None
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in Linux bridge multicast code where a master VLAN's multicast context is freed via RCU while a transmit-path reader (br_multicast_rcv) still sees the enabled flag and re-arms timers, leading to slab corruption in timer management.

Why it matters to the business

Kernel crashes or potential remote code execution on systems using Linux bridging with multicast and VLANs, causing downtime, data loss, or full host compromise; low exploitability reduces immediate risk but kernel-level impact remains severe if triggered.

How an attack unfolds

An attacker sends IGMP packets toward a bridge device; when a master VLAN is deleted the context is drained without clearing the enabled flag, allowing the receive path to re-arm timers on already-freed memory.

How to fix it

Apply the upstream kernel patch that restricts the br_vlan_is_brentry() test to the enable path only and always clears BR_VLFLAG_MCAST_ENABLED under the lock before deinitializing master VLAN contexts.

How to confirm the fix worked

Confirm the fix is present by inspecting bridge multicast code for the corrected br_vlan_is_brentry() placement and test that master-VLAN deletion no longer leaves the flag set.

Typical attack path

  1. Send IGMP or multicast traffic to the bridge interface
  2. Trigger deletion of a master VLAN entry
  3. Force the transmit path to access the freed multicast context
  4. Trigger timer manipulation leading to use-after-free

How to detect it

Scan kernel logs and crash reports for KASAN slab-use-after-free signatures mentioning detach_if_pending, br_multicast_host_join, or br_multicast_rcv during bridge transmit activity.

What your security team should do

  • Prioritize kernel updates containing the bridge multicast fix
  • Disable multicast on bridges where not required
  • Monitor kernel logs for KASAN or slab-use-after-free reports involving br_multicast functions

The record

In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: fix use-after-free of a master VLAN's multicast context br_multicast_toggle_one_vlan() clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before stopping a VLAN's multicast context. That is the teardown handshake: lockless readers gate on the flag through br_multicast_ctx_should_use() -> br_multicast_ctx_vlan_disabled(), so once it is cleared under the lock no reader can arm the context again. For a master VLAN the handshake never runs. __vlan_del() clears BRIDGE_VLAN_INFO_BRENTRY before calling br_vlan_put_master(), so br_multicast_toggle_one_vlan(masterv, false) returns early on !br_vlan_is_brentry(vlan): the flag stays set and br->multicast_lock is never taken. br_vlan_put_master() then drains the context in br_multicast_ctx_deinit() and frees the VLAN through call_rcu(), while a reader still inside rcu_read_lock() sees the context as enabled and re-arms it. The port and port-VLAN branch of the function has no br_vlan_is_brentry() test and flips the flag under br->multicast_lock, so it is not affected. The reader is the bridge transmit path. For a master VLAN br_multicast_rcv() selects brmctx = &vlan->br_mcast_ctx with pmctx = NULL, so IGMP sent to the bridge device re-arms the context's timers after br_multicast_ctx_deinit() has already stopped them. BUG: KASAN: slab-use-after-free in detach_if_pending+0x412/0x4a0 Write of size 8 at addr ffff88810ac39918 by task brmc/601 __mod_timer+0x51a/0xc50 br_multicast_host_join+0x25b/0x390 __br_multicast_add_group+0x468/0x530 br_ip4_multicast_add_group+0x1a0/0x260 br_multicast_rcv+0x2cda/0x61e0 br_dev_xmit+0x6c4/0x1540 Allocated by task 610: br_vlan_add+0x111/0xb40 br_vlan_info+0x370/0x3e0 Freed by task 0: kfree+0x1a7/0x4f0 rcu_core+0x7dc/0x10a0 Only test br_vlan_is_brentry() when enabling, like the br_multicast_ctx_vlan_global_disabled() test next to it. Disabling then always clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before br_multicast_ctx_deinit() drains the context.

Affected packages

Ecosystem Package Introduced Fixed