CVE-2026-52912

What it actually does

This is a Linux kernel use-after-free in the netfilter NFQUEUE path for bridged traffic. When a bridge packet is passed up locally, the kernel may rewrite the packet buffer's device pointer from the physical ingress port to the bridge master device. NFQUEUE correctly keeps references to several netfilter state devices, but prior to the fix it did not hold a reference to the device stored in skb->dev for the lifetime of the queued packet. If the bridge master device is removed or brought down while the packet is queued, reinjection of the packet can re-enter the receive path with skb->dev pointing to freed memory, causing a kernel use-after-free. Practical outcomes are most likely kernel crash or denial of service; depending on kernel configuration, memory layout, and attacker control over heap reuse, use-after-free bugs can sometimes become privilege escalation or code execution primitives, but no public exploit maturity is indicated for this issue.

Why it matters to the business

Systems using Linux bridging together with netfilter/NFQUEUE can be exposed to kernel instability if an attacker or local operator can cause suitable bridged packets to be queued while the bridge device is removed or transitions down. The most direct business risk is outage of affected hosts, appliances, firewalls, container nodes, virtualization hosts, or network gateways relying on Linux bridge filtering. Because EPSS is currently low, the issue is not listed in CISA KEV, and no known exploitation is reported, urgency is lower than for actively exploited kernel bugs; however, the impact can be operationally significant where Linux hosts perform packet bridging, transparent firewalling, container networking, or virtual switch functions.

How an attack unfolds

An attacker would need to reach a system that uses Linux bridge networking with netfilter hooks that queue packets to userspace through NFQUEUE. They send traffic that traverses the bridge LOCAL_IN path and is selected by an NFQUEUE rule. While that packet remains queued awaiting a userspace verdict, the bridge master device is removed, brought down, or otherwise freed. When the NFQUEUE verdict is later reinjected, the kernel may use the stale skb->dev pointer and dereference freed memory in the bridge receive path. In realistic scenarios, this most reliably produces a kernel oops, panic, or networking failure. More advanced exploitation would require precise timing, knowledge of kernel heap behavior, and a way to influence memory reuse after the device object is freed. There are no named threat actors, ransomware use, KEV listing, or public exploit maturity reported in the supplied data.

How to fix it

Upgrade to a Linux kernel version that contains the fix for the netfilter nf_queue bridge skb->dev reference handling issue. The fix stores skb->dev in the queue entry, holds a device reference for the lifetime of the queued packet, and uses the saved device during NETDEV_DOWN handling. If distribution-specific fixed versions are not available, apply the vendor kernel security update that references this vulnerability or backport the upstream patch. As interim risk reduction, avoid using NFQUEUE on bridged traffic where feasible, reduce or remove bridge LOCAL_IN NFQUEUE rules, restrict who can change network device state, and limit untrusted traffic exposure to systems acting as Linux bridges or transparent filtering devices. Reboot may be required after kernel upgrade unless live patching is supported and the vendor provides a live patch.

How to confirm the fix worked

Confirm that the running kernel, not only the installed package, includes the vendor fix. Check the active kernel with uname -a and compare it to the distribution advisory for this vulnerability. Review netfilter rules for NFQUEUE usage on bridge paths, including nftables, iptables, ebtables, and bridge-family rules. Where safe in a lab, reproduce the vulnerable condition by queuing bridged LOCAL_IN traffic, delaying NFQUEUE verdicts, and cycling the bridge device; patched kernels should not produce KASAN use-after-free reports, kernel oopses, or crashes. In production, validate by confirming updated kernel packages are installed, the host has been rebooted into the fixed kernel, and bridge/NFQUEUE configurations have been reviewed for exposure.

Typical attack path

1. Identify a Linux target using bridge networking and netfilter rules that send bridged packets to NFQUEUE.
2. Send traffic that enters the bridge and is processed on the bridge LOCAL_IN path.
3. Ensure the traffic matches a rule that queues the packet to userspace through NFQUEUE.
4. Delay or withhold the userspace NFQUEUE verdict so the packet remains queued.
5. Trigger or race a bridge master device down/removal event while the queued packet still references it.
6. Allow the queued packet to be reinjected or dropped through the affected path.
7. Cause a stale skb->dev pointer to be used, potentially resulting in kernel use-after-free, crash, or denial of service.

How to detect it

Look for evidence of kernel instability associated with bridged NFQUEUE traffic and device down/removal events. Useful sources include journalctl, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, crash dumps, kdump/vmcore analysis, kernel oops reports, KASAN reports, and monitoring alerts for unexpected host reboot or network appliance failover. Search for use-after-free reports involving bridge receive functions, netfilter queue functions, skb device handling, or NETDEV_DOWN processing. Correlate any kernel oops or panic with recent bridge interface changes, network namespace/container teardown, virtualization bridge changes, nftables/iptables NFQUEUE verdict delays, or userspace queue consumers such as Suricata, Snort, custom libnetfilter_queue applications, or transparent filtering daemons. There are no known public exploitation campaigns or named threat actors in the supplied data, so detection should focus on crash forensics and timing correlation rather than fixed network payload signatures.

• KASAN: use-after-free
• BUG: KASAN: use-after-free
• use-after-free in br_netif_receive_skb
• br_netif_receive_skb
• br_pass_frame_up
• nf_queue
• nfnetlink_queue
• NFQUEUE
• NETDEV_DOWN
• skb->dev
• general protection fault
• kernel BUG at net/bridge
• kernel panic
• Oops:
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /proc/net/netfilter/nfnetlink_queue

What your security team should do

• Inventory Linux systems performing bridge networking, transparent firewalling, container networking, virtualization switching, or network appliance functions.
• Prioritize patching systems that combine Linux bridges with NFQUEUE rules, especially internet-facing gateways, multi-tenant virtualization hosts, container nodes, and security appliances.
• Apply the vendor kernel update containing the fix and reboot into the updated kernel, or deploy an approved live patch if available.
• Review nftables, iptables, ebtables, and bridge-family firewall rules for NFQUEUE targets and remove unnecessary queuing on bridged traffic.
• Restrict administrative ability to bring down, delete, or reconfigure bridge devices to trusted operators and automation only.
• Monitor kernel logs for use-after-free, KASAN, bridge, nf_queue, and br_netif_receive_skb crash signatures until all exposed systems are patched.
• Because current EPSS is low, KEV status is false, and exploit maturity is none, treat this as a targeted hardening and stability issue rather than an emergency internet-wide exploitation event, unless local exposure is high.