CVE-2026-43329

What it actually does

This Linux kernel flaw affects netfilter flowtable hardware offload handling. The kernel did not strictly enforce the maximum number of flow offload actions when building action lists, especially for complex IPv6 flows involving Ethernet address mangling, SNAT, DNAT, double VLAN/QinQ handling, redirect, and tunnel-related actions. A local attacker with sufficient privileges to configure relevant networking or nftables/netfilter flowtable state could cause the kernel to write or process more actions than the supported limit, potentially resulting in memory corruption and leading to privilege escalation, kernel crash, or arbitrary kernel-level code execution depending on exploitability and kernel hardening.

Why it matters to the business

Successful exploitation could allow a local attacker to take full control of a Linux system or cause outages by crashing the kernel. The risk is highest on systems where untrusted users, containers, or workloads can obtain network administration capabilities or manipulate nftables/netfilter configuration. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no public exploit maturity indicated, so remediation should be prioritized based on exposure of local multi-user, containerized, or network-appliance workloads rather than treated as confirmed widespread exploitation.

How an attack unfolds

An attacker first needs local access and enough privilege to influence netfilter flowtable configuration, such as CAP_NET_ADMIN or an equivalent capability in a network namespace. They then craft a flowtable hardware-offload scenario with enough combined IPv6-related actions to exceed the previous internal action limit, for example combining address mangling, NAT, VLAN operations, redirect, or tunnel-related behavior. When traffic causes the affected flow to be offloaded, the vulnerable kernel path builds the flow action list without adequately enforcing the maximum action count. This can corrupt kernel memory or destabilize the networking stack. With a reliable exploit, the attacker may escalate privileges to kernel/root level; with a less controlled trigger, the more likely result is a kernel oops, panic, or denial of service.

How to fix it

Upgrade to a Linux kernel version from the operating system or appliance vendor that includes the upstream netfilter flowtable fix which raises the maximum actions per flow and strictly checks action allocation. Because exact fixed package versions vary by distribution and no fixed versions were provided, use vendor advisories and package changelogs to identify kernels containing the netfilter flowtable action-limit patch. If immediate patching is not possible, reduce exposure by disabling or avoiding netfilter flowtable hardware offload, limiting nftables/netfilter administration to trusted administrators only, preventing untrusted containers from receiving CAP_NET_ADMIN or privileged networking access, disabling unprivileged user namespaces where operationally feasible, and monitoring for unexpected nftables or flowtable configuration changes.

How to confirm the fix worked

Confirm the running kernel package is updated to a vendor build that includes the netfilter flowtable action-count validation fix. Validate that all booted systems are actually running the patched kernel, not merely that the package is installed, by checking the active kernel version after reboot. Review nftables configuration for use of flowtables and hardware offload flags, especially IPv6 flowtable rules involving NAT, VLAN, redirect, or tunnel-related behavior. Where mitigation rather than patching is used, verify untrusted users and containers cannot obtain CAP_NET_ADMIN, cannot create network namespaces with administrative network capabilities, and cannot modify nftables/netfilter rules. Security teams can also test in a non-production environment that complex flowtable configurations no longer trigger kernel warnings, KASAN reports, oopses, or panics.

Typical attack path

1. Gain local execution on a vulnerable Linux system.
2. Obtain or abuse the ability to configure networking state, nftables, netfilter flowtables, or a network namespace with CAP_NET_ADMIN-like privileges.
3. Create a complex IPv6 flowtable hardware-offload rule set that combines enough actions to exceed the affected kernel action limit.
4. Generate matching traffic so the kernel attempts to install or process the flow offload action list.
5. Trigger kernel memory corruption or a kernel fault in the netfilter flowtable offload path.
6. Use the corruption for local privilege escalation or cause a denial-of-service crash.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, audit logs, EDR telemetry, shell history, and configuration-management records. Focus on evidence of unexpected nftables/netfilter flowtable creation, hardware offload enablement, IPv6 NAT or VLAN-heavy flow rules, and traffic generation shortly before kernel faults. Useful log sources include journald, /var/log/kern.log, /var/log/messages, auditd execve records, sudo logs, container runtime logs, and orchestration audit logs showing privileged containers or CAP_NET_ADMIN assignment. Kernel artifacts of interest include oops, panic, KASAN, UBSAN, slab corruption, general protection fault, or BUG traces referencing netfilter flowtable offload code paths. Because there are no public exploit indicators and exploitation is local/configuration-driven, absence of network IOCs does not rule out exploitation; prioritize correlation between suspicious nft/netfilter changes and kernel instability.

• flow_action_entry_next
• nf_flow_table_offload
• nft_flow_offload
• netfilter: flowtable
• flags offload
• type filter hook ingress
• BUG: KASAN
• slab-out-of-bounds
• general protection fault
• kernel BUG
• Oops:
• nft add flowtable
• nft add rule
• CAP_NET_ADMIN
• /usr/sbin/nft
• /sbin/nft
• /proc/net/nf_flowtable

What your security team should do

• Inventory Linux systems using nftables/netfilter flowtables or hardware flow offload, especially network appliances, routers, Kubernetes/container hosts, and multi-tenant Linux servers.
• Prioritize kernel updates on systems where untrusted users or workloads may obtain CAP_NET_ADMIN, privileged containers, or network namespace control.
• Reboot systems after kernel package updates and verify the active kernel is the patched version.
• Temporarily disable netfilter flowtable hardware offload where patching is delayed and the feature is not essential.
• Remove CAP_NET_ADMIN and privileged container settings from untrusted workloads; restrict nftables and network namespace administration to trusted operators.
• Monitor audit, shell history, EDR, and configuration-management logs for unexpected nftables, flowtable, VLAN, NAT, or offload configuration changes.
• Review kernel logs for crashes, warnings, KASAN reports, or oops traces involving netfilter flowtable offload functions.
• Track vendor advisories for distribution-specific fixed kernel package versions and backport status.