Skip to main content

Linux Kernel CVE-2026-45860

| EUVDEUVD-2026-32326 HIGH
2026-05-27 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-xwf3-wjqg-p85x
7.5
CVSS 3.1 · Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
SUSE
HIGH
qualitative
Red Hat
7.0 MEDIUM
qualitative

Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
May 30, 2026 - 11:25 vuln.today
CVSS changed
May 30, 2026 - 11:22 NVD
7.5 (HIGH)
Patch available
May 27, 2026 - 19:46 EUVD
CVE Published
May 27, 2026 - 14:16 nvd
UNKNOWN (no severity yet)
CVE Published
May 27, 2026 - 14:16 nvd
HIGH 7.5

DescriptionCVE.org

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

netfilter: nf_conncount: 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 nft_connlimit/xt_connlimit 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

AnalysisAI

Denial of service in the Linux kernel netfilter nf_conncount subsystem allows remote attackers to trigger erroneous connection limit enforcement by establishing more than 8 new tracked connections per jiffy, causing the garbage collector to fall behind and the connection list to wrongly hit its cap. The flaw affects systems using nft_connlimit, xt_connlimit, or OVS connection limit features, with availability impact only (CVSS 7.5, AV:N/AC:L/PR:N/UI:N/A:H). EPSS is very low (0.02%) and no public exploit identified at time of analysis, but the issue is reproducible with common HTTP load tools such as slowhttptest.

Technical ContextAI

nf_conncount is the Linux netfilter helper that tracks the number of connections matching a given key, used by the nft_connlimit and xt_connlimit match modules as well as Open vSwitch (OVS) connection limiting. A prior optimization restricted garbage collection (GC) to at most one pass per jiffy (the kernel's tick unit, typically 1-10 ms). Under sustained connection-establishment pressure, more than 8 new connections per jiffy could be added without GC reclaiming stale entries, causing the in-memory tracked-connection list to grow past the configured limit before cleanup. The fix raises the per-jiffy clean-up cap to 64 and only skips GC when both the same-jiffy guard is active and the increment stays below that cap, restoring accurate limit enforcement under load. No CWE is assigned in the supplied data; the behavior class is best described as incorrect resource-tracking under contention leading to a logic-level limit-enforcement failure.

RemediationAI

Vendor-released patches are available - upgrade to a fixed stable kernel: 5.10.252, 5.15.202, 6.1.165, 6.6.128, 6.12.75, 6.18.14, 6.19.4, or 7.0 (or later), pulling from your distribution's kernel update channel or rebasing onto the corresponding git.kernel.org/stable commits listed in the NVD references. If immediate kernel update is not possible, compensating controls focus on reducing reliance on nf_conncount under high connection-rate conditions: temporarily remove or relax nft_connlimit/xt_connlimit rules that gate critical services so spurious limit hits do not deny legitimate traffic (trade-off: loses per-source connection-flood protection at that layer), or shift connection-limit enforcement upstream to a load balancer, reverse proxy, or stateful firewall appliance that is not affected (trade-off: added latency and a new policy surface to maintain); for OVS deployments, lower the configured connection ceiling well below the rate at which the bug manifests, or rate-limit new flows with meter/policer actions to keep additions per jiffy under the threshold (trade-off: reduces peak legitimate throughput). Increasing CONFIG_HZ also shortens the jiffy window and indirectly raises the effective per-second cap, but requires a kernel rebuild and has system-wide scheduling implications.

Vendor StatusVendor

SUSE

Severity: High
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

CVE-2026-45860 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy