CVE-2026-64032 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
bridge: mcast: Fix a possible use-after-free when removing a bridge port
When per-VLAN multicast snooping is enabled, the bridge iterates over all the bridge ports, disables the per-port multicast context on each port and enables the per-{port, VLAN} multicast contexts instead. The
reverse happens when per-VLAN multicast snooping is disabled.
When global multicast snooping is enabled, the bridge iterates over all the bridge ports and enables the per-port multicast context on each port. The reverse happens when multicast snooping is disabled.
The above scheme can result in a situation where both types of contexts (per-port and per-{port, VLAN}) are enabled on a single bridge port:
# ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1 vlan_filtering 1 # ip link add name dummy1 up master br1 type dummy # ip link set dev br1 type bridge mcast_vlan_snooping 1 # ip link set dev br1 type bridge mcast_snooping 0 # ip link set dev br1 type bridge mcast_snooping 1
This is not intended and it is a problem since the commit cited below. Prior to this commit, when removing a bridge port, br_multicast_disable_port() would disable the per-port multicast context and the per-{port, VLAN} multicast contexts would get disabled when
flushing VLANs.
After this commit, br_multicast_disable_port() only disables the per-port multicast context if per-VLAN multicast snooping is disabled. If both types of contexts were enabled on the port when it was removed, the per-port multicast context would remain enabled when freeing the bridge port, leading to a use-after-free [1].
Fix by preventing the bridge from enabling / disabling the per-port multicast contexts when toggling global multicast snooping if per-VLAN multicast snooping is enabled.
[1]
ODEBUG: free active (active state 0) object: ffff88810f8bda78 object type: timer_list hint: br_ip6_multicast_port_query_expired (net/bridge/br_multicast.c:1927) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1b1/0x3e0, CPU#5: swapper/5/0 [...]
Call Trace: <IRQ> __debug_check_no_obj_freed (lib/debugobjects.c:1116) kfree (mm/slub.c:2620 mm/slub.c:6250 mm/slub.c:6565) kobject_cleanup (lib/kobject.c:689) rcu_do_batch (kernel/rcu/tree.c:2617) rcu_core (kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) __irq_exit_rcu (kernel/softirq.c:656 kernel/softirq.c:496 kernel/softirq.c:735) irq_exit_rcu (kernel/softirq.c:752) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1061 (discriminator 47) arch/x86/kernel/apic/apic.c:1061 (discriminator 47)) </IRQ>
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/19/2026
This vulnerability exists within the linux kernel's bridge multicast implementation and represents a use-after-free condition that can occur during bridge port removal operations. The issue stems from improper handling of multicast context management when transitioning between different multicast snooping configurations. When per-vlan multicast snooping is enabled alongside global multicast snooping, the system maintains two distinct types of multicast contexts on individual bridge ports. The first context type manages multicast behavior at the port level, while the second manages behavior at the combination of port and vlan level. This dual-context management creates a scenario where both context types can become active simultaneously on the same bridge port, which was not the intended behavior.
The technical flaw manifests when a bridge port is removed while both context types are enabled. Prior to the problematic commit, the removal process would properly disable both context types during port cleanup. However, after the commit, the br_multicast_disable_port() function only disables per-port multicast contexts when per-vlan multicast snooping is disabled. When both context types remain active during port removal, the per-port multicast context persists in an enabled state while the underlying port structure is being freed, creating a use-after-free scenario where freed memory is still referenced by active timer structures.
The operational impact of this vulnerability can be significant as it may lead to system instability and potential privilege escalation opportunities. The use-after-free condition occurs during kernel memory management operations when the system attempts to free objects that are still actively referenced, potentially causing kernel panics or allowing attackers to manipulate kernel memory structures. This type of vulnerability falls under CWE-416 which specifically addresses use-after-free conditions in software systems. The vulnerability is particularly concerning because it operates at the kernel level where memory corruption can lead to complete system compromise.
The fix implemented prevents the bridge from enabling or disabling per-port multicast contexts when toggling global multicast snooping if per-vlan multicast snooping is enabled, effectively creating a clear separation between these two management schemes. This approach aligns with ATT&CK technique T1068 which involves exploiting vulnerabilities in privilege escalation, as the use-after-free could potentially allow attackers to gain elevated privileges through kernel memory manipulation. The vulnerability demonstrates how complex interaction between different kernel subsystems can create unexpected behavior patterns that lead to security flaws. Organizations should ensure their systems are updated with patches addressing this specific issue, particularly those running bridge configurations with multicast snooping enabled in mixed per-port and per-vlan scenarios. The fix prevents the conflicting state where both context types could be active simultaneously, thereby eliminating the race condition that leads to the use-after-free condition during bridge port removal operations.