CVE-2026-45859
High · 7.5CVSS
7.5
EPSS
0.6%
Published
May 27, 2026
CISA due date
—
Cloudanix analysis
Some Linux systems that inspect network traffic can mistakenly drop certain UDP traffic, potentially disrupting services that depend on it.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Denial of service
- Remediation
- Patch
- Effort
- Low
- Patch risk
- Low
What it actually does
This Linux kernel flaw affects the netfilter nfnetlink_queue path when UDP Generic Segmentation Offload/Generic Receive Offload traffic is processed through NFQUEUE without the userspace queue application advertising GSO support. The kernel performs the shared-unconfirmed conntrack check after packet segmentation, causing cloned packet segments to make the conntrack entry appear shared. As a result, packets that should be queued to userspace for inspection or reinjection can instead be dropped. The practical technical impact is a remotely triggerable denial of service for affected UDP flows traversing netfilter/NFQUEUE policy paths; confidentiality and integrity are not directly impacted.
Why it matters to the business
Systems that rely on Linux netfilter NFQUEUE for firewalling, packet inspection, intrusion prevention, traffic filtering, or policy enforcement can experience unexpected UDP traffic loss. This may disrupt DNS, VPN, VoIP, telemetry, gaming, streaming, QUIC/HTTP3, or other UDP-based services depending on where NFQUEUE is used. The CVSS availability impact is high, but current public exploitation maturity is listed as none, EPSS is low, and it is not currently in CISA KEV, so remediation should be prioritized for internet-facing or high-throughput UDP gateways rather than treated as an active mass-exploitation emergency.
How an attack unfolds
An attacker sends UDP traffic that reaches an affected Linux host or gateway where netfilter rules direct packets into NFQUEUE and the userspace queue consumer has not enabled the F_GSO capability. When the traffic is received as an aggregated UDP GRO/GSO packet with an unconfirmed conntrack entry, the vulnerable kernel path segments the packet before checking whether the conntrack entry is shared and unconfirmed. Segmentation clones the packet state and increases the conntrack reference count, causing the later check to misclassify the entry and drop the packets instead of queueing them for userspace handling. By repeatedly sending traffic that matches the NFQUEUE path, an attacker can cause sustained packet loss for affected UDP flows, resulting in service degradation or outage.
How to fix it
Upgrade to a Linux kernel version that includes the upstream fix for nfnetlink_queue performing the shared-unconfirmed conntrack check before segmentation and annotating later segments for reinjection-time checking. No exact fixed package versions were provided in the input, so use the fixed kernel packages from the relevant Linux distribution or vendor advisory once available. As mitigations, reduce or avoid NFQUEUE use for untrusted high-volume UDP paths where possible, update NFQUEUE userspace applications to support GSO where applicable, disable or tune UDP GRO/GSO offload features if operationally acceptable, and apply rate limiting or filtering for abusive UDP traffic before it reaches NFQUEUE.
How to confirm the fix worked
Confirm the running kernel includes the vendor fix for the nfnetlink_queue shared-unconfirmed check ordering issue. Validate that systems using NFQUEUE can process UDP GRO/GSO traffic without unexpected drops by testing representative UDP flows through the same ruleset and userspace queue application. Review netfilter rules for NFQUEUE targets, confirm whether the userspace queue consumer supports GSO/F_GSO, and monitor packet counters before and after upgrade to ensure UDP drops no longer increase under normal or test load. Where offload mitigation is used, verify with interface offload settings and packet-path testing that UDP GRO/GSO behavior is actually changed.
Typical attack path
- Identify or target a Linux system acting as a firewall, gateway, load balancer, appliance, or host-based packet filter using netfilter NFQUEUE.
- Send UDP traffic that matches rules directing packets to NFQUEUE.
- Ensure traffic characteristics cause UDP GRO/GSO aggregation before NFQUEUE processing.
- Trigger the vulnerable path where the queue application lacks F_GSO support and the conntrack entry is still unconfirmed.
- Cause the kernel to drop affected packet segments instead of queueing and reinjecting them normally.
- Repeat the traffic pattern to sustain UDP packet loss and availability impact.
How to detect it
To assess possible prior exploitation or triggering, focus on evidence of unexplained UDP packet loss on Linux systems using NFQUEUE. Review firewall and packet-filter telemetry from iptables, nftables, NFQUEUE consumers, conntrack, kernel logs, interface counters, and service logs for correlated increases in UDP drops or outages. Look for NFQUEUE rules receiving UDP traffic, userspace queue applications that do not advertise GSO support, and time windows where UDP services degraded without corresponding application errors. Useful sources include journalctl or syslog for kernel/netfilter messages, iptables/nftables rule counters, conntrack statistics, NFQUEUE application logs, interface drop counters, flow logs, and upstream load balancer or service health checks. Network evidence is likely behavioral rather than a stable payload IOC: repeated high-volume UDP flows that are aggregated by GRO/GSO and routed to NFQUEUE are the relevant pattern. There are no public named threat actors or ransomware campaigns associated with this issue in the provided data.
- NFQUEUE
- nfnetlink_queue
- nf_ct_drop_unconfirmed
- skb_gso_segment
- F_GSO
- udp_gro
- GRO
- GSO
What your security team should do
- Inventory Linux systems that use iptables, nftables, or firewall appliances with NFQUEUE targets, especially internet-facing gateways and systems handling high-volume UDP traffic.
- Prioritize kernel updates on systems where UDP service availability is business-critical or where NFQUEUE is used inline for enforcement.
- Check vendor advisories for fixed kernel package versions and deploy them through normal emergency or expedited patch channels based on exposure.
- If patching is delayed, consider temporary mitigations such as bypassing NFQUEUE for selected UDP flows, enabling GSO support in the queue consumer, disabling UDP GRO/GSO where acceptable, or applying upstream UDP rate limits.
- Monitor for spikes in UDP packet drops, conntrack anomalies, NFQUEUE backlog changes, and service-level symptoms such as DNS, VPN, VoIP, QUIC, or telemetry failures.
- Because this issue is not currently KEV-listed and has low EPSS, balance urgency against exposure: prioritize exposed packet-processing systems over general-purpose Linux hosts that do not use NFQUEUE.
The record
In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation Ulrich reports a regression with nfqueue: If an application did not set the 'F_GSO' capability flag and a gso packet with an unconfirmed nf_conn entry is received all packets are now dropped instead of queued, because the check happens after skb_gso_segment(). In that case, we did have exclusive ownership of the skb and its associated conntrack entry. The elevated use count is due to skb_clone happening via skb_gso_segment(). Move the check so that its peformed vs. the aggregated packet. Then, annotate the individual segments except the first one so we can do a 2nd check at reinject time. For the normal case, where userspace does in-order reinjects, this avoids packet drops: first reinjected segment continues traversal and confirms entry, remaining segments observe the confirmed entry. While at it, simplify nf_ct_drop_unconfirmed(): We only care about unconfirmed entries with a refcnt > 1, there is no need to special-case dying entries. This only happens with UDP. With TCP, the only unconfirmed packet will be the TCP SYN, those aren't aggregated by GRO. Next patch adds a udpgro test case to cover this scenario.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|