CVE-2026-45860: Linux kernel · Uncontrolled Resource Consumption
Affects Linux kernelSource CVE Database V5
Not known to be exploited · CVSS 7.5 High · fixed in fa85432d58c8e74b39333edbf8d28df2985dfc79 : patch Linux kernel soon.
Data as of 26 Oct 2026, 15:59 UTC
- EPSS
- 0.7% chance of exploitation in 30 days – higher than 54% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- CISA SSVC
- Exploitation
- No evidence of active exploitation and no public proof of concept
- Automatable
- Attackers can reliably automate steps 1–4 of the kill chain
- Technical impact
- Limited control over the software or limited information exposure
CISA SSVC assessment, 2026-10-16.
- Patch
- Available – fixed in fa85432d58c8e74b39333edbf8d28df2985dfc79, a5c9e14e0e8923218ae881d5e78c990c07694966, 0792ad077d776c2dcf20f0484e2461ded1b77a24 +7
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 27 May 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
Description
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
References
- git.kernel.org/stable/c/a5c9e14e0e8923218ae881d5e78c990c07694966 (opens in a new tab)
- git.kernel.org/stable/c/13eede458fdf231f1bf96a398feea4ad1553f14c (opens in a new tab)
- git.kernel.org/stable/c/fa85432d58c8e74b39333edbf8d28df2985dfc79 (opens in a new tab)
- git.kernel.org/stable/c/0792ad077d776c2dcf20f0484e2461ded1b77a24 (opens in a new tab)
- git.kernel.org/stable/c/3d0994ed0aa1fc0a2c5e620b765e8defdd021bff (opens in a new tab)
- git.kernel.org/stable/c/6e5fa7add3e76da068a478d905be64be8fa4e80a (opens in a new tab)
- git.kernel.org/stable/c/0af0812baf2d363176c9b76fc07e33f13aede8db (opens in a new tab)
- git.kernel.org/stable/c/21d033e472735ecec677f1ae46d6740b5e47a4f3 (opens in a new tab)