CVE-2026-45901

What it actually does

This flaw is a Linux kernel netfilter/nf_tables race-condition and locking issue in the nftables reset path. When nftables reset operations, ipset listing, and iptables-nft rules that reference sets run concurrently, the kernel can enter a circular lock dependency involving commit_mutex, nfnl_subsys_ipset, and nlk_cb_mutex. The result is a local denial of service condition: affected systems may hang, stall networking/firewall management operations, trigger kernel lockup warnings, or require a reboot. The CVSS vector indicates local access with low privileges is required, with no confidentiality or integrity impact but high availability impact.

Why it matters to the business

Successful exploitation can disrupt Linux hosts by causing kernel-level hangs or severe networking/firewall control-plane instability. On servers that rely on nftables, iptables-nft, or ipset for firewalling, container networking, service mesh enforcement, or host-based access controls, this can cause outages, degraded packet-filter management, failed automation, and emergency reboots. The issue is not currently in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so broad exploitation pressure appears low; however, availability-sensitive Linux systems should still be patched through normal kernel maintenance because local users or compromised low-privilege processes may be able to trigger service disruption.

How an attack unfolds

An attacker first needs local code execution or shell access on an affected Linux system. They then cause concurrent netfilter operations that exercise the vulnerable locking path: an nftables reset operation, an ipset list operation, and an iptables-nft rule operation using the set match path. By repeatedly running these operations in parallel, the attacker attempts to force the kernel into the circular lock dependency. If successful, the system may experience hung tasks, stalled firewall tooling, kernel lockup symptoms, or a broader availability failure requiring administrative intervention or reboot. There is no indication from the provided data that public exploit code, named threat actors, or active in-the-wild exploitation are currently associated with this vulnerability.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the upstream fix reverting commit_mutex usage in the nf_tables reset path. Because no exact fixed package versions were provided, use vendor advisories for the affected distribution, kernel flavor, appliance, or cloud image to identify the corrected kernel build. After installing the fixed kernel, reboot into it and remove or decommission older vulnerable kernels where operationally feasible. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting who can run firewall-management tooling, monitoring for repeated nft/ipset/iptables-nft invocations, and applying least privilege to automation accounts that manage host firewall rules. On systems where nftables/ipset functionality is not required, consider disabling unused firewall-management components only if this does not weaken security controls.

How to confirm the fix worked

Confirm the system is running a vendor kernel build that includes the nf_tables reset-path fix, not merely that the package is installed. Validate with kernel package metadata, distribution security advisories, and the active kernel version after reboot. Review dmesg or journal logs for lock dependency warnings involving commit_mutex, nfnl_subsys_ipset, nlk_cb_mutex, nf_tables, nft reset, ipset list, or iptables-nft. In a non-production test environment, reproduce representative firewall automation workloads involving nftables, ipset, and iptables-nft set matches and confirm the system no longer reports circular locking, hung tasks, soft lockups, or stalled firewall commands. Avoid stress-testing production systems because the vulnerable behavior is availability-impacting.

Typical attack path

1. Gain local access to an affected Linux host as an unprivileged or low-privileged user.
2. Verify that nftables/iptables-nft and ipset tooling or kernel functionality are present.
3. Run or script concurrent nft reset, ipset list, and iptables-nft set-match operations.
4. Repeat the concurrent operations to trigger the circular kernel lock dependency.
5. Cause firewall-management hangs, kernel lockup symptoms, host instability, or denial of service.
6. Wait for operational impact such as failed network policy updates, service disruption, or administrator-initiated reboot.

How to detect it

To determine whether this was already triggered or exploited, review kernel and system logs rather than looking for network payloads. Primary sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd process execution logs, EDR command telemetry, shell history where available, and sudo logs. Look for kernel warnings about circular locking dependencies, hung tasks, soft lockups, or blocked tasks that reference nf_tables, nftables, ipset, iptables-nft, commit_mutex, nfnl_subsys_ipset, or nlk_cb_mutex. Correlate those events with local execution of nft reset, ipset list, and iptables-nft commands, especially if run repeatedly or concurrently by an unexpected user, script, container, CI job, or automation account. Because the vulnerability causes denial of service rather than code execution, useful evidence is likely to be timing correlation between command execution and system instability, firewall tooling hangs, watchdog events, service restarts, or forced reboots.

• possible circular locking dependency detected
• circular lock dependency
• commit_mutex
• nfnl_subsys_ipset
• nlk_cb_mutex
• nf_tables
• nft reset
• ipset list
• iptables-nft
• -m set
• hung task
• blocked for more than
• soft lockup
• hard lockup
• BUG: workqueue lockup
• INFO: task
• kernel: nf_tables

What your security team should do

• Prioritize patching Linux systems where untrusted users, shared workloads, containers, CI jobs, or automation accounts can execute local commands.
• Track vendor kernel advisories and upgrade to the first available fixed kernel for each affected Linux distribution or appliance image.
• After patching, reboot systems and verify the active kernel is the fixed version.
• Review privileged and semi-privileged automation that invokes nft, ipset, or iptables-nft and ensure access is limited to trusted operators and service accounts.
• Monitor kernel logs for circular lock dependency, hung task, soft lockup, or netfilter-related warnings until patch coverage is complete.
• Treat unexplained host hangs or repeated firewall-management stalls on affected kernels as potential exploitation or vulnerability triggering and collect forensic logs before reboot when possible.
• Because this is not KEV-listed, not ransomware-associated, and has low EPSS, handle through risk-based kernel maintenance unless the system is availability-critical or locally multi-tenant.