MEDIUM 5.5

CVE-2026-52921: Linux Netfilter IPset Range Iterator Boundary Vulnerability

A bug in the Linux kernel's netfilter ipset module causes certain hash-based set variants to iterate past their intended range boundaries when processing IPv4 addresses. When a user requests a range of IP addresses to be processed—for example, in firewall or traffic filtering rules—the iterator should stop after handling the last address in that range. Instead, it advances one more step, potentially moving the traversal state outside the original request boundary. This can cause problems on retry operations, where the system might resume from an incorrect position rather than the intended starting point. The issue affects four specific ipset hash variants used in network filtering configurations.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.5 MEDIUM · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weaknesses (CWE)
CWE-835
Affected products
10 configuration(s)
Published / Modified
2026-06-24 / 2026-07-08

NVD description (verbatim)

In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: stop hash:* range iteration at end The following hash set variants: hash:ip,mark hash:ip,port hash:ip,port,ip hash:ip,port,net iterate IPv4 ranges with a 32-bit iterator. The iterator must stop once the last address in the requested range has been processed. Advancing it once more can move the traversal state past the end of the request, so a later retry may continue from an unintended position. Handle the iterator increment explicitly at the end of the loop and stop once the upper bound has been processed. This keeps the existing retry behaviour intact for valid ranges while preventing traversal from continuing past the original boundary.

8 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-52921 is an off-by-one iterator boundary issue in the Linux kernel's netfilter ipset subsystem, specifically affecting hash:ip,mark, hash:ip,port, hash:ip,port,ip, and hash:ip,port,net set types. These variants use a 32-bit iterator to traverse IPv4 address ranges. The vulnerability occurs because the iterator is incremented after the last address in a requested range is processed, moving the traversal state beyond the upper boundary. On subsequent retry operations (a legitimate part of the ipset retry mechanism), this causes the traversal to resume from an unintended position rather than correctly re-entering the loop at the boundary. The fix involves explicit iterator increment handling at the end of the loop with a boundary check that stops iteration once the upper bound has been processed, preserving the existing retry behavior for valid ranges while preventing out-of-bounds traversal.

Business impact

For organizations relying on Linux-based firewalls, traffic shaping, or network access control lists built on netfilter ipset, this vulnerability could lead to inconsistent rule application. If an administrator configures range-based filtering rules and the system needs to retry processing (due to load, congestion, or other factors), the ipset may resume iteration from an incorrect position, potentially skipping addresses or applying rules inconsistently. In high-availability or heavily loaded environments where retries are more frequent, this inconsistency could result in unintended traffic allowing or blocking, affecting network availability or security posture. The impact is localized to systems using the affected hash set variants for range-based filtering and is triggered by legitimate retry conditions rather than external attack.

Affected systems

Linux kernel systems running versions that include the vulnerable netfilter ipset code and making use of the four affected hash set variants: hash:ip,mark, hash:ip,port, hash:ip,port,ip, and hash:ip,port,net. This includes Linux distributions (Red Hat, Debian, Ubuntu, SUSE, etc.) and custom Linux deployments used in networking appliances, firewalls, and edge computing platforms. Systems not using ipset or not using these specific hash variants are not affected. Desktop and workstation Linux systems are generally lower risk unless they are configured as network gateways or run container orchestration with network policy enforcement.

Exploitability

This vulnerability requires local access (privilege level: low, indicating non-root user context) and cannot be exploited remotely. An attacker would need to be present on the system to trigger the retry condition that exposes the iterator boundary bug. No user interaction is required once local access is established. The vulnerability is not listed on the CISA KEV catalog, indicating it has not been observed in active exploitation in the wild. The barrier to exploitation is moderate: an attacker must understand ipset configuration and deliberately craft range-based operations that trigger retry scenarios. The practical attack surface is limited because most systems do not frequently encounter the exact conditions that force retries on range operations.

Remediation

Apply a kernel update that includes the fix for CVE-2026-52921. The patch modifies the iterator logic in the affected netfilter ipset hash variants to explicitly handle the loop increment and check the upper bound before advancing the iterator. Verify the patch version in your Linux distribution's security advisory or kernel release notes. After patching, no configuration changes are required; existing ipset rules will continue to function correctly with the improved boundary handling. For systems unable to patch immediately, consider limiting the use of range-based ipset operations or reducing retry-prone workloads (e.g., offloading traffic to prevent congestion-induced retries) as a temporary mitigation.

Patch guidance

Consult your Linux distribution's security advisories for the specific kernel version that addresses CVE-2026-52921. Major distributions typically backport fixes to supported stable kernel series. For Red Hat Enterprise Linux, check RHSA advisories; for Debian/Ubuntu, check the security tracker; for other distributions, verify against their respective kernel security pages. The fix is a low-risk change isolated to ipset iterator handling and should be included in standard kernel updates without compatibility impact. Test the patched kernel in a staging environment before production deployment to confirm that existing ipset rules continue to function as intended, though no rule changes should be necessary.

Detection guidance

Monitor kernel logs for unexpected behavior in netfilter ipset operations, particularly error messages or warnings related to hash set iteration or range processing. Network behavior analytics may reveal inconsistent rule application (e.g., traffic that should be blocked passing through, or vice versa) when ipset range rules are in use. Kernel audit logs can be configured to track ipset operations, though this may have performance implications on high-traffic systems. The most reliable detection is simply confirming your kernel version against the patched version provided by your distribution. No special IDS or IPS signatures are necessary because the vulnerability is not exploited remotely.

Why prioritize this

CVE-2026-52921 merits medium priority attention because it directly affects firewall and network access control rule consistency, but only when specific conditions (ipset range operations with retry scenarios) are met. The CVSS score of 5.5 (Medium) reflects local-only access requirement and availability impact. Organizations should prioritize patching systems that rely heavily on ipset for network filtering, particularly in production network infrastructure where rule inconsistency poses business risk. Desktop and non-networking systems are lower priority. The lack of active exploitation (not on KEV) means this is not an emergency, but it should be included in the next planned maintenance window for networking-critical systems.

Risk score, explained

The CVSS 3.1 base score of 5.5 is justified by the local attack vector (not remotely exploitable), low privilege requirement, and high availability impact (denial of service through inconsistent rule application). The lack of confidentiality or integrity impact (both scored as None) reflects that the vulnerability does not leak data or corrupt system files; it affects the correct processing of firewall rules. The vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H indicates a local attacker with low privilege can reliably trigger the issue without user interaction, causing disruption to network rule enforcement. Environmental factors may elevate this score for organizations where ipset range rules are critical to production security.

Frequently asked questions

Does this affect me if I don't use ipset or only use simple IP whitelists/blacklists?

No. The vulnerability is specific to four hash set variants (hash:ip,mark, hash:ip,port, hash:ip,port,ip, hash:ip,port,net) when configured with range-based operations. If you use ipset with individual IP entries or different set types, you are not affected. Check your ipset configuration with 'ipset list' to see which set types you use.

Can this vulnerability be exploited remotely over the network?

No. The vulnerability requires local access to the system and is triggered by specific retry conditions during range iteration. It cannot be exploited by remote attackers sending network traffic. However, in shared hosting or multi-tenant environments, a local unprivileged user could potentially trigger it.

Will the patch break my existing ipset rules or firewall configurations?

No. The patch is a bug fix that corrects the boundary handling of range iteration. Your existing rules will continue to work, but with correct behavior. The fix actually prevents the unintended traversal that was the bug, so you may see improved consistency in rule application.

Is this vulnerability being actively exploited?

No. The vulnerability is not listed on the CISA KEV catalog, which tracks vulnerabilities with confirmed exploitation in the wild. This is not an emergency patch, but should be applied during your normal maintenance cycle.

This analysis is provided for informational purposes and reflects the state of vulnerability information as of the publication date. Patch version numbers and specific distribution-level fixes should be verified directly against vendor security advisories. Organizations should conduct their own risk assessment based on their specific infrastructure, ipset configurations, and operational context. This vulnerability has not been confirmed as actively exploited, but all security patches should be evaluated and tested before production deployment. SEC.co makes no warranty regarding the completeness or accuracy of remediation guidance; consult your system vendor and security team for final remediation decisions. Source: NVD (public-domain), retrieved 2026-07-30. Analysis generated by SEC.co (claude-haiku-4-5).