CVE-2026-53220

What it actually does

This flaw is a Linux kernel denial-of-service issue in the netfilter bridge path. When a packet is queued to userspace through NFQUEUE and later reinjected, the kernel can dereference a bridge-port reference that is no longer valid if the network device was removed from the bridge or moved under another virtual device in the interim. The vulnerable path is associated with ebtables/nftables bridge redirect handling, specifically ebt_redirect_tg(), and can result in a NULL pointer dereference or invalid bridge reinjection state, causing a kernel panic.

Why it matters to the business

Successful exploitation can crash affected Linux systems, causing abrupt service interruption, failed network forwarding, container or virtual networking disruption, and potential outage of workloads relying on bridge networking. The risk is most relevant on hosts using Linux bridge, netfilter bridge rules, NFQUEUE, ebtables/nftables bridge filtering, container networking, virtualization hosts, routers, firewalls, or packet-inspection components. This vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no known public exploit maturity, and has a low EPSS score, so remediation should be prioritized based on exposure to bridge/NFQUEUE configurations rather than broad internet exploitability alone.

How an attack unfolds

An attacker must be able to influence the vulnerable bridge/netfilter packet path and create or win a timing condition where a packet is queued to userspace and then reinjected after the associated bridge port has been removed from the bridge or moved to another upper device such as a macvlan. In practical terms, this is most likely to be exploited by a local privileged user, compromised container or service with CAP_NET_ADMIN, or an operator of a network namespace that can manipulate bridge membership and netfilter queueing rules. The attacker generates traffic that matches a bridge-family rule using NFQUEUE or redirect behavior, removes or reassigns the involved interface before reinjection occurs, and causes the kernel to process stale bridge state. On vulnerable kernels, that can lead to a kernel panic and host-wide denial of service.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the netfilter bridge-port revalidation fix for this issue. Because no product-specific fixed versions were provided, track the advisory for the exact kernel package version for each distribution in use and upgrade all affected kernels, including virtualization hosts, container hosts, firewall appliances, routers, and systems using custom kernels. Reboot into the fixed kernel and remove old vulnerable kernels where operationally feasible. If immediate patching is not possible, reduce exposure by limiting CAP_NET_ADMIN and privileged-container access, avoiding untrusted workloads with control over network namespaces, reviewing bridge-family NFQUEUE/redirect rules, disabling unnecessary ebtables/nftables bridge filtering, and avoiding configurations where userspace queue verdicts race with bridge-port removal.

How to confirm the fix worked

Confirm the running kernel version includes the vendor fix, not just that the package is installed. Validate with commands such as uname -a and the distribution package manager, then reboot if the fixed kernel is installed but not running. Review nftables, iptables, ebtables, and bridge configuration to identify bridge-family NFQUEUE or redirect rules that may have exposed the host. Where safe, test in a non-production environment by exercising bridge NFQUEUE traffic and interface removal/reassignment workflows to confirm the system drops invalid reinjections rather than panicking. Verify that untrusted containers and services do not retain CAP_NET_ADMIN or privileged network namespace control unless required.

Typical attack path

1. Gain the ability to manipulate Linux networking state, such as CAP_NET_ADMIN, root access, or control of a privileged container/network namespace.
2. Ensure the host has bridge-family netfilter processing in use, such as ebtables/nftables bridge rules with NFQUEUE or redirect behavior.
3. Generate packets that traverse the Linux bridge and are queued to userspace for inspection or verdict handling.
4. Before the queued packet is reinjected, remove the relevant interface from the bridge or move it under another virtual device such as macvlan.
5. Trigger reinjection of the queued packet into the bridge path.
6. Cause the vulnerable kernel code to dereference invalid or missing bridge-port state, resulting in a kernel panic and denial of service.

How to detect it

To assess whether this was already exploited or triggered, review persistent kernel logs, dmesg output, journald kernel entries, syslog, crash dumps, and kdump/vmcore artifacts for kernel panics or NULL pointer dereferences that include bridge netfilter, NFQUEUE, reinjection, or ebtables redirect call paths. Correlate crash timestamps with network configuration changes such as interfaces being removed from a bridge, moved to macvlan or other upper devices, network namespace changes, or container lifecycle events. Review auditd, shell history, orchestration logs, container runtime logs, and network-manager/systemd-networkd logs for commands or API activity involving ip link set <iface> nomaster, bridge link delete, brctl delif, nft/iptables/ebtables rule changes, or NFQUEUE verdict-handling services. Indicators are strongest when a kernel panic stack includes ebt_redirect_tg or nf_reinject and occurs immediately after bridge membership changes while NFQUEUE rules are active.

• BUG: kernel NULL pointer dereference
• kernel panic - not syncing
• Oops: 0000
• ebt_redirect_tg
• br_port_get_rcu
• nf_reinject
• nfnetlink_queue
• nf_queue
• NFQUEUE
• NETFILTER_FAMILY_BRIDGE
• CONFIG_BRIDGE_NETFILTER
• ip link set * nomaster
• brctl delif
• bridge link delete
• macvlan
• nft add rule bridge
• ebtables

What your security team should do

• Inventory Linux systems that use bridge networking, ebtables/nftables bridge rules, NFQUEUE, container networking, virtualization bridges, firewalling, routing, or packet-inspection workflows.
• Prioritize kernel updates for systems where bridge-family NFQUEUE/redirect behavior is enabled or where untrusted workloads can manipulate network namespaces.
• Restrict CAP_NET_ADMIN, privileged containers, host networking, and direct access to network namespace manipulation tools for non-administrative workloads.
• Review nftables, iptables, and ebtables policies for bridge-family NFQUEUE and redirect usage; remove unnecessary rules or redesign high-risk packet queuing paths until patched.
• Enable persistent kernel logging and crash dump collection so kernel panics can be triaged if the issue is triggered.
• Monitor kernel logs for panic traces involving ebt_redirect_tg, NFQUEUE reinjection, bridge netfilter, or bridge-port removal activity.
• Because EPSS is low, KEV is false, and exploit maturity is currently none, treat this as configuration-dependent but operationally important for high-availability Linux networking hosts.