CVE-2026-45860: netfilter: nf_conncount: increase the connection clean up limit to 64
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfconncount: increase the connection clean up limit to 64
After the optimization to only perform one GC per jiffy, a new problem was introduced. If more than 8 new connections are tracked per jiffy the list won't be cleaned up fast enough possibly reaching the limit wrongly.
In order to prevent this issue, only skip the GC if it was already triggered during the same jiffy and the increment is lower than the clean up limit. In addition, increase the clean up limit to 64 connections to avoid triggering GC too often and do more effective GCs.
This has been tested using a HTTP server and several performance tools while having nftconnlimit/xtconnlimit or OVS limit configured.
Output of slowhttptest + OVS limit at 52000 connections:
slow HTTP test status on 340th second: initializing: 0 pending: 432 connected: 51998 error: 0 closed: 0 service available: YES
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Increase the netfilter nf_conncount connection clean up limit to 64 to prevent the connection tracking list from not being cleaned up fast enough and reaching the limit.
Linux kernel netfilter (nf_conncount) connection clean up limit = 64 - Configuration
Adjust the nf_conncount garbage collection logic to only skip GC when it was already triggered during the same jiffy, to avoid triggering GC too often while still cleaning up effectively.
Linux kernel netfilter (nf_conncount) GC skipping logic = skip only if GC already triggered in the same jiffy
Event History
Frequently Asked Questions
Which systems are most likely to be affected?
Systems using the Linux kernel netfilter nf_conncount functionality with nft_connlimit, xt_connlimit, or an OVS limit configured are the configurations identified in the available data.
What traffic pattern is needed to trigger the issue?
More than eight new tracked connections in a single jiffy can cause cleanup to fall behind after the one-GC-per-jiffy optimization. This can allow the connection list to reach its limit incorrectly.
What is the operational impact?
The issue can cause the connection-count list to reach its limit even when it should have been cleaned up, which can affect connection handling and availability. The reported severity vector indicates network reachability, low attack complexity, no privileges, no user interaction, and an availability-only impact.