CVE-2026-64414

What it actually does

This is a Linux kernel netfilter denial-of-service flaw involving packet handling paths that inspect socket buffers containing unreadable fragments. When traffic is processed by netfilter components such as xt_u32, nfnetlink_queue, nfnetlink_log, or fragment-gathering logic, unreadable skb fragments can cause incorrect handling instead of safely rejecting or limiting inspection to readable packet data. The resolved behavior is to bail out, hotdrop, return an error, or restrict processing to the packet’s linear readable portion. The expected impact is loss of availability, such as kernel instability, packet-processing failure, or system crash, rather than data theft or privilege escalation.

Why it matters to the business

An unauthenticated remote attacker may be able to disrupt Linux systems that process affected traffic through netfilter, causing outages for firewalls, routers, gateways, Kubernetes nodes, load balancers, VPN endpoints, or application servers that rely on Linux packet filtering. The issue is not currently listed in CISA KEV, has low EPSS, and has no known public exploit maturity in the provided data, but the network-reachable and unauthenticated nature makes timely kernel patching important for internet-facing or traffic-processing Linux hosts.

How an attack unfolds

An attacker sends crafted network traffic that reaches a vulnerable Linux host or passes through it while netfilter rules are active. If the traffic is represented internally as an skb with unreadable fragments, affected netfilter code paths may attempt to inspect more data than is safely readable or may incorrectly treat a failed copy as a successful match. Rules or logging paths using xt_u32, NFQUEUE, NFLOG, or related fragment handling can trigger the vulnerable behavior. Successful exploitation would aim to crash or destabilize the kernel or packet-processing path, producing a denial of service. There is no indication from the provided data that the vulnerability enables code execution, credential theft, or data modification.

How to fix it

Upgrade affected Linux kernels to vendor-provided fixed versions as soon as they are available. Because no exact affected products or fixed package versions were provided, use the relevant distribution advisory for the running kernel package and confirm it includes the upstream netfilter fixes for unreadable skb fragments in xt_u32, fragment handling, nfnetlink_queue, and nfnetlink_log. Prioritize internet-facing systems, packet-forwarding hosts, firewalls, gateways, load balancers, container hosts, and systems using iptables/nftables rules that invoke u32 matching, NFQUEUE, or NFLOG. If immediate patching is not possible, reduce exposure by disabling or simplifying rules that use u32, NFQUEUE, or NFLOG where operationally feasible, limiting untrusted traffic to affected hosts, and placing vulnerable systems behind upstream filtering or rate limiting. Reboot into the fixed kernel after installation; installing a kernel package without rebooting does not remove exposure from the running kernel.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is fixed. Check the active version with `uname -a` and compare it against the distribution’s security advisory or fixed kernel package. Verify whether affected netfilter functionality is in use with `iptables-save`, `ip6tables-save`, and `nft list ruleset`, looking for u32 matches, NFQUEUE targets, and NFLOG targets. Confirm loaded modules with `lsmod | grep -E 'xt_u32|nfnetlink_queue|nfnetlink_log|nf_log|nf_tables|ip_tables|ip6_tables'`. After patching and rebooting, confirm the old vulnerable kernel is not running and that no pending reboot is required. For high-assurance validation, test representative firewall, queueing, and logging rules in a staging environment and confirm malformed or fragmented traffic is dropped or handled without kernel warnings, oopses, or packet-processing failures.

Typical attack path

1. Identify a Linux system that is reachable over the network or forwards traffic for other systems.
2. Send crafted traffic that produces fragmented or otherwise unreadable skb fragment conditions inside the kernel network stack.
3. Ensure the traffic is evaluated by affected netfilter functionality, such as u32 matching, NFQUEUE handling, NFLOG logging, or fragment-related processing.
4. Trigger unsafe handling of unreadable packet fragments in the vulnerable kernel code path.
5. Cause packet-processing failure, kernel instability, or a crash, resulting in denial of service.

How to detect it

Look for evidence of denial-of-service activity rather than post-compromise artifacts. Primary sources are kernel logs, system journals, crash dumps, firewall logs, packet captures, and netfilter queue/logging telemetry. Review `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, `journalctl -k`, and crash dump directories for kernel oops, panic, BUG, WARNING, NULL dereference, general protection fault, soft lockup, or watchdog messages involving netfilter, xt_u32, nfnetlink_queue, nfnetlink_log, skb_copy_bits, skb fragments, or packet fragment handling. Correlate crashes or packet-processing outages with spikes in fragmented IP traffic, unusual TCP segmentation patterns, NFQUEUE backlog growth, NFLOG volume spikes, or repeated packets hitting u32/NFQUEUE/NFLOG rules. Check whether incidents occurred before a reboot into a fixed kernel. Because no public exploitation, threat actor, or ransomware use is indicated in the provided data, detection should focus on suspicious traffic preceding kernel instability rather than known malware indicators.

• xt_u32
• nfnetlink_queue
• nfnetlink_log
• skb_copy_bits
• skb_frags_readable
• unreadable frags
• unreadable fragments
• BUG: kernel
• kernel BUG
• WARNING: CPU
• Oops:
• Kernel panic
• general protection fault
• NULL pointer dereference
• soft lockup
• watchdog: BUG: soft lockup
• NETFILTER
• NFQUEUE
• NFLOG
• iptables-save
• ip6tables-save
• nft list ruleset
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• journalctl -k
• /var/crash/
• /var/lib/systemd/coredump/

What your security team should do

• Patch and reboot Linux systems that are internet-facing, route or filter untrusted traffic, or run security controls based on netfilter.
• Inventory use of u32, NFQUEUE, and NFLOG across iptables, ip6tables, and nftables rulesets to identify higher-risk systems.
• If patching must be delayed, temporarily remove or reduce affected netfilter rule paths where business operations allow.
• Monitor kernel logs for crashes, oopses, warnings, or repeated netfilter-related errors after unusual fragmented or high-volume traffic.
• Prioritize availability-sensitive infrastructure such as firewalls, gateways, Kubernetes nodes, load balancers, VPN concentrators, and edge servers.
• Track Linux distribution advisories for exact fixed kernel versions, because fixes are typically backported and version numbers differ by vendor.
• Because this issue is not KEV-listed and has low EPSS in the provided data, prioritize based on exposure and role rather than treating it as confirmed active exploitation.