CVE-2026-45897

What it actually does

This is a Linux kernel race condition in the netfilter nftables counter reset path. Concurrent counter dump-and-reset operations can read the same counter value and both subtract it, causing counter underflow or inconsistent internal accounting. Exploitation requires local access and sufficient privileges to interact with nftables/netfilter, typically CAP_NET_ADMIN or an equivalent container/user-namespace configuration. The primary impact is availability: malformed or repeated concurrent reset activity may destabilize netfilter accounting behavior and, depending on kernel state and build, could contribute to service disruption or kernel instability.

Why it matters to the business

Systems that rely on Linux nftables for firewalling, routing policy, container networking, or traffic accounting may be exposed to local denial-of-service risk if untrusted users or workloads can obtain netfilter administration privileges. The current public exploit maturity is listed as none, EPSS is very low, and it is not in the CISA KEV catalog, so broad internet-scale exploitation is unlikely; however, the issue matters more on multi-tenant Linux hosts, container platforms, developer workstations, and systems where user namespaces or delegated network administration are enabled.

How an attack unfolds

An attacker first needs local execution on a Linux system and a way to perform nftables operations, most commonly through CAP_NET_ADMIN, privileged container access, or a configuration that permits netfilter manipulation from a namespace. The attacker creates or identifies nftables counters, then launches multiple concurrent dump-and-reset requests against the same counter objects. Because vulnerable kernels do not serialize the fetch-and-reset sequence, two reset operations can observe the same counter value and both subtract it. Repeating this race can cause counter underflow and inconsistent kernel-side counter state. The practical outcome is generally denial of service or disruption of packet-filtering/accounting behavior rather than data theft or privilege escalation.

How to fix it

Update the Linux kernel to a vendor release that includes the nft_counter fix which serializes counter fetch-and-reset operations with a spinlock. Because no exact fixed versions were provided, use the relevant distribution advisory for the deployed kernel stream and confirm the patch for `netfilter: nft_counter: serialize reset with spinlock` is present. Where immediate patching is not possible, reduce exposure by limiting CAP_NET_ADMIN, avoiding privileged containers, disabling unneeded user namespaces where operationally feasible, restricting use of the `nft` utility to trusted administrators, and monitoring or rate-limiting automation that performs nftables counter resets.

How to confirm the fix worked

Confirm the running kernel is from a vendor build that includes the nft_counter serialization patch. Validate by checking distribution security advisories, kernel changelogs, or package metadata for the netfilter/nft_counter fix. After patching, reboot into the updated kernel and verify with `uname -r` and package-manager tooling that the active kernel is the fixed build, not merely installed alongside it. Review nftables administrative workflows to ensure only trusted users or services can execute counter reset operations, and verify containers do not receive CAP_NET_ADMIN unless explicitly required.

Typical attack path

1. Gain local code execution on a Linux host or inside a container with sufficient netfilter privileges.
2. Obtain or abuse CAP_NET_ADMIN, privileged container settings, or namespace behavior that permits nftables operations.
3. Create or target existing nftables counters used by firewall, routing, or traffic-accounting rules.
4. Run parallel nftables dump-and-reset operations against the same counter objects.
5. Trigger the race so multiple reset operations subtract the same observed counter value.
6. Repeat the condition to corrupt counter accounting and potentially cause service disruption or kernel/networking instability.

How to detect it

Look for evidence of suspicious nftables counter reset activity combined with local privilege or container context. Useful sources include Linux auditd logs, shell history, process accounting, EDR process telemetry, sudo logs, container runtime logs, Kubernetes audit logs, and kernel logs from journald or `/var/log/kern.log`. Investigate bursts of concurrent `nft reset counter`, `nft reset counters`, or related nftables commands, especially when executed by unexpected users, service accounts, CI jobs, or containers. In audit logs, correlate executions of `/usr/sbin/nft` or `/sbin/nft` with CAP_NET_ADMIN use, privileged container starts, namespace creation, and netlink/netfilter configuration events. In kernel logs, search for warnings, oopses, panics, lockups, or nf_tables/netfilter messages around the same time. There are no known public threat actors or ransomware campaigns associated with this issue in the provided intelligence, so detection should focus on behavioral anomalies rather than known malware signatures.

• nft reset counter
• nft reset counters
• nft reset rules
• /usr/sbin/nft
• /sbin/nft
• comm="nft"
• NETFILTER_CFG
• CAP_NET_ADMIN
• nf_tables
• nft_counter
• nft_counter_reset
• netfilter: nft_counter
• kernel: BUG:
• kernel: WARNING:
• kernel: Oops
• privileged=true
• --cap-add=NET_ADMIN

What your security team should do

• Prioritize patching multi-user Linux systems, container hosts, Kubernetes nodes, network appliances, and hosts where CAP_NET_ADMIN is delegated.
• Inventory systems running Linux kernels with nftables/netfilter enabled and identify those permitting untrusted local users or privileged containers.
• Restrict CAP_NET_ADMIN and privileged container use; remove the capability from workloads that do not strictly require it.
• Disable or constrain unprivileged user namespaces where compatible with business requirements and distribution guidance.
• Monitor for high-frequency or concurrent `nft reset` activity, especially from nonstandard users, automation accounts, or containerized processes.
• Review kernel logs for netfilter, nf_tables, warnings, oopses, or unexplained networking instability following nftables reset activity.
• Track vendor advisories for the exact fixed kernel versions applicable to each distribution and ensure systems have rebooted into the fixed kernel.