CVE-2026-72247: netfilter: nf_conncount: fix zone comparison in tuple dedup

Published Aug 15, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfconncount: fix zone comparison in tuple dedup

The "already exists" dedup logic in nfconncountadd() decides whether a connection has already been counted and can be skipped instead of incrementing the connlimit count. It compares the conntrack zone of a list entry with the zone of the connection being added using nfctzoneid() and nfctzoneequal(), passing conn->zone.dir or zone->dir as the direction argument.

Those helpers take enum ipconntrackdir values: IPCTDIRORIGINAL is 0 and IPCTDIRREPLY is 1. However, zone->dir is a u8 bitmask: NFCTZONEDIRORIG is 1, NFCTZONEDIRREPL is 2 and NFCTDEFAULTZONEDIR is 3. Passing that bitmask as the enum direction shifts the meaning of every non-zero value. An ORIG-only zone passes 1 and is tested as REPLY, while REPL-only and default zones pass 2 or 3 and test bits beyond the valid direction range. In those cases nfctzoneid() can fall back to NFCTDEFAULTZONEID instead of using the real zone id, so different zones can be treated as equal and dedup collapses to tuple equality alone.

nfconncount stores and compares the original-direction tuple for a connection. If an skb already has an attached conntrack entry, getctortuplefromskb() explicitly copies ct->tuplehash[IPCTDIRORIGINAL].tuple, regardless of the packet's ctinfo. Therefore the zone comparison in the tuple dedup path must use IPCTDIRORIGINAL as well; the zone direction bitmask describes where a zone id applies, not which direction this conncount tuple represents.

Fix the two dedup comparisons by passing IPCTDIRORIGINAL directly. Do not special-case NFCTDEFAULTZONEDIR and do not compare raw zone ids: using the existing helpers with IPCTDIRORIGINAL preserves the direction-aware NFCTDEFAULTZONEID fallback. A default bidirectional zone contains the ORIG bit, so it naturally returns the real zone id; reply-only zones continue to fall back for original-direction tuple comparisons.

Affected Software

1 affected component
Linux Kernel

Event History

Aug 15, 2026
CVE Published
via MITRE·05:54 AM
Data Sourced
via MITRE·05:54 AM
Description
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-72247?

CVE-2026-72247 has a risk level assigned as 37.

2

What systems are affected by CVE-2026-72247?

CVE-2026-72247 affects the Linux kernel implementations that utilize the netfilter nf_conncount feature.

3

How do I fix CVE-2026-72247?

To fix CVE-2026-72247, you should update your Linux kernel to the patched version that resolves the vulnerability.

4

What impact does CVE-2026-72247 have if exploited?

Exploitation of CVE-2026-72247 can lead to incorrect connection count behavior, affecting the connlimit functionality.

5

Is there any workaround for CVE-2026-72247 before applying patches?

There are no specific workarounds for CVE-2026-72247; applying the kernel update is the recommended action.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203