CVE-2026-45913

What it actually does

This flaw is a Linux kernel bridge multicast database accounting bug in VLAN-aware bridge contexts. Under specific bridge, VLAN filtering, multicast snooping, MDB add, link-state, and MDB flush operations, the kernel can decrement the multicast database entry counter without a matching prior increment. That counter underflow/inconsistency triggers a kernel WARN in the bridge multicast code path, specifically around br_multicast_port_ngroups_dec_one(), br_multicast_del_pg(), and br_mdb_flush(). On systems configured to panic on kernel warnings, this can escalate from a warning into a local denial of service through a kernel panic or reboot. The issue requires local ability to manipulate network bridge configuration, typically privileges such as CAP_NET_ADMIN or equivalent administrative network-control capability.

Why it matters to the business

Successful exploitation can disrupt Linux hosts that use kernel bridge networking, VLAN filtering, or multicast snooping, including virtualization, container, lab, network-appliance, and software-defined networking environments. The primary business risk is availability loss: an authorized local user, compromised low-privileged service with network administration capability, or container/workload granted excessive network capabilities may be able to crash or destabilize a host. The risk is highest on systems where kernel warnings are configured to trigger panic/reboot and on platforms that delegate network namespace or bridge-management capabilities to tenants, containers, or automation. This vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so remediation should be prioritized by exposure to local users and delegated network administration rather than by evidence of broad internet exploitation.

How an attack unfolds

An attacker first obtains local code execution on a Linux system or in a network namespace with sufficient privileges to create or modify bridge devices, VLAN settings, and multicast database entries. They create or target a bridge with VLAN filtering and multicast snooping enabled, add a port to the bridge, and insert a permanent multicast database entry tied to a VLAN. They then manipulate the bridge state and multicast VLAN snooping settings so the kernel does not update the internal multicast database entry count in the expected way. Finally, they flush MDB entries, causing the deletion path to decrement a counter that was not incremented. The kernel detects the inconsistent state and emits a WARN in net/bridge/br_multicast.c. If the system is configured with panic_on_warn, or if repeated triggering destabilizes the system, the host can suffer denial of service.

How to fix it

Apply a Linux kernel update that includes the upstream bridge multicast fix for keeping mdb_n_entries synchronized for VLAN contexts. No specific fixed version was provided in the supplied data, so use the latest security-supported kernel from the operating system or appliance vendor and confirm the vendor advisory explicitly includes the fix for this issue. Where immediate patching is not possible, reduce exposure by restricting CAP_NET_ADMIN, disabling unprivileged user namespaces where not required, avoiding delegation of bridge/VLAN/MDB management to untrusted workloads, and limiting container or virtualization profiles that allow network administration. Consider disabling panic-on-warn behavior on systems where availability is more important than crash-on-warning diagnostics, while recognizing this only reduces outage impact and does not correct the kernel bug. Avoid unnecessary use of Linux bridge multicast snooping and multicast VLAN snooping on hosts that do not require those features.

How to confirm the fix worked

Confirm the running kernel package is at or above the vendor-fixed build that contains the bridge multicast MDB counter fix. Check vendor changelogs or kernel commit backports for language such as 'net: bridge: mcast: always update mdb_n_entries for vlan contexts'. Validate configuration exposure by identifying systems with Linux bridge modules loaded and bridges using VLAN filtering or multicast snooping. Review whether untrusted users, containers, CI jobs, or network automation have CAP_NET_ADMIN or equivalent permissions. In a non-production test environment only, attempt the documented bridge/MDB sequence and confirm the system no longer logs the WARN in br_multicast_port_ngroups_dec_one or br_multicast_del_pg. Also confirm that panic_on_warn is set according to operational policy.

Typical attack path

1. Gain local execution on a Linux system or inside a network namespace with bridge-management privileges such as CAP_NET_ADMIN.
2. Create or identify a Linux bridge using VLAN filtering and multicast snooping.
3. Attach a network interface or dummy interface to the bridge.
4. Add a multicast database entry for a VLAN, such as a permanent MDB group entry.
5. Change the bridge link state and enable multicast VLAN snooping in a sequence that leaves the MDB entry counter unsynchronized.
6. Flush MDB entries for the bridge.
7. Trigger a kernel warning in the bridge multicast deletion path, potentially causing a panic or reboot if kernel warning panics are enabled.

How to detect it

Look for evidence in kernel logs and system journals that the bridge multicast warning path was triggered. Primary sources include dmesg output, journald kernel entries, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump artifacts, and host monitoring events for kernel WARN, OOPS, panic, or unexpected reboot. Search for WARN traces referencing net/bridge/br_multicast.c, br_multicast_port_ngroups_dec_one, br_multicast_del_pg, br_mdb_flush, br_mdb_del_bulk, rtnl_mdb_del, or the message 'n == 0'. Correlate those events with recent execution of bridge, ip, or network automation commands that create bridges, enable vlan_filtering, enable mcast_snooping or mcast_vlan_snooping, add MDB entries, or flush MDB entries. In containerized environments, review audit logs, container runtime logs, and orchestration events for workloads granted CAP_NET_ADMIN before the warning or reboot. If auditd is enabled, search for execution of /sbin/bridge, /usr/sbin/bridge, /sbin/ip, or /usr/sbin/ip with arguments involving 'mdb', 'flush', 'vlan_filtering', 'mcast_snooping', or 'mcast_vlan_snooping'.

• WARNING: net/bridge/br_multicast.c:718
• br_multicast_port_ngroups_dec_one
• br_multicast_port_ngroups_dec
• br_multicast_del_pg
• br_mdb_flush_pgs
• br_mdb_flush
• br_mdb_del_bulk
• rtnl_mdb_del
• n == 0
• bridge mdb flush
• bridge mdb add
• mcast_vlan_snooping 1
• mcast_snooping 1
• vlan_filtering 1
• kernel.panic_on_warn
• ------------[ cut here ]------------

What your security team should do

• Inventory Linux systems that run kernel bridge networking, container networking, virtualization networking, or SDN components, especially where VLAN filtering and multicast snooping are enabled.
• Patch affected Linux kernels using vendor security updates; prioritize multi-user systems and hosts that delegate network administration capabilities to containers, tenants, or automation.
• Audit and remove unnecessary CAP_NET_ADMIN privileges from containers, services, build jobs, and user sessions.
• Disable unprivileged user namespaces where they are not required, particularly on shared hosts.
• Review sysctl kernel.panic_on_warn and crash policy to understand whether this warning can become an immediate reboot condition.
• Search historical kernel logs for bridge multicast WARN traces to determine whether the condition has already been triggered.
• Add monitoring for kernel WARN/OOPS events involving net/bridge/br_multicast.c and br_mdb_flush paths.
• If patching is delayed, avoid enabling bridge multicast VLAN snooping on systems where untrusted users can affect bridge configuration.