CVE-2026-52921

What it actually does

This flaw is a boundary-handling bug in the Linux kernel netfilter ipset code for IPv4 range iteration in the hash:ip,mark, hash:ip,port, hash:ip,port,ip, and hash:ip,port,net set types. When processing a requested IPv4 range, the iterator can advance once after the upper bound has already been processed. If the operation is retried, traversal can resume from an unintended position outside the original range. The practical impact is most likely incorrect or unexpected ipset processing, excessive iteration, or instability in firewall rule management paths, rather than remote code execution. Exploitation generally requires the ability to issue ipset/netfilter configuration operations, typically through CAP_NET_ADMIN or equivalent administrative privileges in a network namespace.

Why it matters to the business

Systems that rely on Linux netfilter/ipset for firewalling, network segmentation, abuse blocking, container networking, or traffic policy enforcement could experience incorrect policy behavior or disruption during ipset range operations. Because exploitation requires netfilter administration capability, the primary risk is from compromised privileged workloads, containers granted network administration rights, malicious insiders, or automation systems that can manage firewall sets. The issue is not currently listed in CISA KEV, is not reported as ransomware-used, has very low EPSS, and has no public exploit maturity indicated, so remediation should be handled through normal kernel patching unless the environment exposes CAP_NET_ADMIN broadly or uses ipset heavily for critical controls.

How an attack unfolds

An attacker first needs access to a local context that can manage netfilter/ipset state, such as root, CAP_NET_ADMIN, or a privileged container with network administration permissions. The attacker then creates or manipulates one of the affected hash-based ipset types and submits IPv4 range operations designed to reach the range boundary condition. Because the kernel iterator can advance beyond the requested upper bound, a retry path may continue from an unintended address position. Depending on the surrounding operation and workload, this can result in unexpected set processing, policy inconsistency, excessive CPU work, failed firewall automation, or kernel/network stack instability. There is no indication from the supplied data that this vulnerability enables unauthenticated remote compromise.

How to fix it

Apply the Linux kernel update from the operating system or appliance vendor that includes the upstream fix titled "netfilter: ipset: stop hash:* range iteration at end." Because no exact fixed package versions were supplied, use the distribution security advisory or kernel changelog for the deployed kernel branch to identify the corrected version. After patching, reboot into the updated kernel where required. As interim mitigation, restrict CAP_NET_ADMIN and privileged-container access, disable unneeded unprivileged user namespaces where operationally feasible, limit who or what can run ipset/nftables/iptables management commands, and avoid untrusted automation submitting arbitrary large IPv4 range operations to affected ipset types.

How to confirm the fix worked

Confirm that systems are running a kernel build containing the netfilter/ipset fix, not merely that the package is installed. Validate with the vendor advisory, kernel package changelog, or source commit history referencing "netfilter: ipset: stop hash:* range iteration at end." On Linux hosts, compare the running kernel from `uname -r` against the fixed vendor package level and reboot if the running kernel is still older. Where testing is possible, exercise ipset operations involving the affected hash set types and IPv4 ranges at boundary values, then confirm operations complete within expected bounds and do not produce unexpected set contents, retries, stalls, or kernel warnings. Also validate that non-administrative users and containers do not retain CAP_NET_ADMIN unless explicitly required.

Typical attack path

1. Obtain local privileges sufficient to configure netfilter/ipset, such as CAP_NET_ADMIN or root in a relevant network namespace.
2. Create or target an ipset using one of the affected set types: hash:ip,mark, hash:ip,port, hash:ip,port,ip, or hash:ip,port,net.
3. Submit IPv4 range operations that exercise the end-of-range iterator boundary, especially large or edge-case ranges.
4. Trigger retry behavior so the traversal resumes from an unintended position after the iterator has advanced past the requested upper bound.
5. Leverage the resulting incorrect ipset processing to disrupt firewall management, cause unexpected policy state, or degrade network/security controls.

How to detect it

There are no universal indicators proving exploitation of this flaw, because the vulnerable path is a kernel ipset iterator bug and may not emit a distinctive log message. Investigate historical evidence of unusual netfilter/ipset administration, especially from unexpected users, containers, automation accounts, or processes. Useful sources include auditd command and syscall logs, shell history, sudo logs, EDR process telemetry, container runtime events, Kubernetes audit logs for privileged pods or NET_ADMIN capability grants, and kernel logs for soft lockups, warnings, or unusual netfilter/ipset failures. Hunt for creation or modification of hash:ip,mark, hash:ip,port, hash:ip,port,ip, and hash:ip,port,net sets with very large IPv4 ranges or ranges ending at boundary addresses such as 255.255.255.255. Correlate suspicious ipset activity with unexpected firewall policy changes, network outages, failed security automation runs, or privileged container activity.

• hash:ip,mark
• hash:ip,port
• hash:ip,port,ip
• hash:ip,port,net
• ipset create
• ipset add
• ipset restore
• ipset save
• CAP_NET_ADMIN
• NET_ADMIN
• NETLINK_NETFILTER
• netfilter: ipset
• soft lockup
• kernel: watchdog: BUG: soft lockup
• 255.255.255.255

What your security team should do

• Inventory Linux systems, appliances, container hosts, and network/security platforms that use netfilter ipset or expose ipset functionality through automation.
• Prioritize patching systems where CAP_NET_ADMIN is granted to containers, CI/CD jobs, network plugins, or non-core administrative services.
• Update affected kernels through the appropriate vendor-supported channel and reboot into the fixed kernel.
• Review privileged container and namespace policies; remove CAP_NET_ADMIN wherever it is not strictly required.
• Monitor for unusual ipset management activity involving the affected hash set types and large IPv4 ranges.
• Add regression checks to firewall automation pipelines to verify ipset range operations do not create unexpected entries or excessive processing.
• Treat evidence of suspicious ipset manipulation as a potential post-compromise activity, because exploitation requires meaningful local network-administration privileges.