CVE-2026-64032

What it actually does

This is a Linux kernel bridge multicast-snooping use-after-free in the network bridge subsystem. A locally authenticated attacker with sufficient networking privileges, typically CAP_NET_ADMIN or equivalent ability to create and modify bridge interfaces, can manipulate bridge multicast snooping and per-VLAN multicast snooping state so that both per-port and per-port/VLAN multicast contexts remain enabled on a bridge port. When that port is removed, a timer or multicast context associated with the freed bridge-port object can remain active and later dereference freed memory. Depending on kernel configuration, heap layout, timing, and available primitives, the result can range from a kernel warning or crash to local privilege escalation through kernel memory corruption.

Why it matters to the business

Successful exploitation can compromise the host operating system, allowing a lower-privileged local user or containerized workload with network-administration capabilities to crash the system or potentially gain elevated privileges. Systems that use Linux bridges for virtualization, containers, software-defined networking, hypervisors, lab environments, or network appliances are most relevant. The vulnerability is not known to be in CISA KEV, not known to be used in ransomware campaigns, and currently has low EPSS and no public exploit maturity indicated, but kernel privilege-escalation flaws should still be treated as high priority where untrusted users or workloads can obtain network namespace or bridge-management capabilities.

How an attack unfolds

An attacker first obtains local access to a Linux system and sufficient permissions to administer network links or a network namespace. They create or control a Linux bridge with VLAN filtering and multicast snooping features enabled, attach a port to it, enable per-VLAN multicast snooping, then toggle global multicast snooping in a sequence that leaves both the per-port multicast context and the per-port/VLAN multicast contexts active. The attacker then removes the bridge port. Because the per-port multicast timer/context is not fully disabled in the vulnerable code path, the bridge-port object can be freed while an associated timer remains active. When the timer later fires or the stale object is processed, the kernel accesses freed memory. A simple exploit may cause a kernel warning, BUG, or denial of service; a more advanced exploit would attempt to shape kernel heap allocation and reuse the freed object to gain code execution or escalate privileges in kernel context.

How to fix it

Apply a Linux kernel update from the operating-system or appliance vendor that includes the upstream bridge multicast fix preventing per-port multicast contexts from being toggled while per-VLAN multicast snooping is enabled. Because no exact fixed package versions were provided, track the vendor advisory for the affected distribution kernel stream and update to the first patched kernel or later, then reboot into the patched kernel. As compensating controls, restrict CAP_NET_ADMIN, unprivileged user namespaces, container network-administration capabilities, and access to bridge-management tools such as iproute2 on multi-user or multi-tenant systems. Where operationally feasible, avoid enabling per-VLAN multicast snooping on Linux bridges until patched. Remove unnecessary bridge devices and prevent untrusted workloads from creating bridges, veth pairs, dummy interfaces, or changing bridge multicast settings.

How to confirm the fix worked

Confirm the system is running a kernel build that contains the vendor’s fix, not merely that the package is installed; verify the active kernel with uname -r and the distribution package manager. Review vendor changelogs or kernel source packaging for the bridge multicast fix associated with preventing per-port multicast context changes while per-VLAN multicast snooping is enabled. On test systems only, security teams can validate exposure by attempting the documented configuration sequence with ip link to create a bridge, enable mcast_vlan_snooping, toggle mcast_snooping, and remove the port while monitoring dmesg for ODEBUG, use-after-free, timer_list, or br_multicast warnings. Do not run proof-of-concept sequences on production systems because the failure mode may be a kernel crash. Also validate that untrusted users and workloads cannot obtain CAP_NET_ADMIN or create privileged network namespaces.

Typical attack path

1. Gain local execution on a Linux host, container, or namespace where network administration operations are permitted.
2. Create or access a Linux bridge device with VLAN filtering and multicast snooping capabilities.
3. Attach a bridge port, such as a dummy, veth, tap, or physical interface, to the bridge.
4. Enable per-VLAN multicast snooping on the bridge.
5. Toggle global multicast snooping off and on in a sequence that leaves incompatible multicast contexts active on the same bridge port.
6. Remove the bridge port, causing the bridge-port object to be freed while a multicast timer/context may still reference it.
7. Trigger or wait for the stale timer/context to execute, producing a use-after-free condition.
8. Abuse the resulting memory corruption for denial of service or, if exploit primitives are reliable, kernel privilege escalation.

How to detect it

Look for evidence of prior exploitation in kernel logs, persistent journal entries, crash dumps, audit logs, and command/process telemetry. Relevant sources include dmesg, /var/log/kern.log, /var/log/messages, systemd-journald kernel facility logs, kdump/vmcore artifacts, auditd execve records, EDR process telemetry, container runtime logs, and shell history where available. Search for kernel warnings involving debugobjects, active timer_list objects, bridge multicast functions, br_multicast, br_ip6_multicast_port_query_expired, and use-after-free-like crashes after bridge or port removal. Also look for suspicious use of ip link commands that create bridge devices, set mcast_snooping or mcast_vlan_snooping, attach dummy/veth/tap interfaces as bridge ports, toggle multicast snooping, and then delete or detach the port. Because exploitation may only cause kernel memory corruption or a crash, absence of grep-able indicators does not prove absence of exploitation; correlate unexpected reboots, kernel panics, oops reports, and local privilege changes around bridge configuration events.

• ODEBUG: free active (active state 0) object
• object type: timer_list
• br_ip6_multicast_port_query_expired
• br_multicast_disable_port
• net/bridge/br_multicast.c
• __debug_check_no_obj_freed
• WARNING: lib/debugobjects.c:629
• 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
• type bridge mcast_vlan_snooping
• type bridge mcast_snooping
• vlan_filtering 1
• mcast_querier 1

What your security team should do

• Inventory Linux systems that use bridges, including container hosts, hypervisors, Kubernetes nodes, virtualization platforms, network appliances, and systems using veth, tap, dummy, or bridge interfaces.
• Prioritize patching systems where untrusted users, containers, CI jobs, or delegated administrators can obtain CAP_NET_ADMIN or create network namespaces.
• Update to a vendor kernel containing the fix and reboot systems into the patched kernel; verify the active runtime kernel after maintenance.
• Temporarily remove CAP_NET_ADMIN from containers and service accounts unless explicitly required.
• Disable or restrict unprivileged user namespaces where not needed, especially on shared compute or multi-tenant hosts.
• Audit for bridge configurations using multicast snooping, VLAN filtering, and per-VLAN multicast snooping.
• Monitor kernel logs for bridge multicast use-after-free symptoms, ODEBUG free-active timer warnings, and unexpected host crashes or reboots.
• Treat unexplained kernel crashes on bridge/container hosts as potentially security-relevant until logs and configuration history are reviewed.