CVE-2026-52935: Linux kernel · Race Condition
Affects Linux kernelSource CVE Database V5
Not known to be exploited · CVSS 7.8 High · fixed in f9b38a8fbfa07f1deaf7ee1eb38fa8b21ea13990 : patch Linux kernel soon.
Data as of 26 Oct 2026, 17:16 UTC
- EPSS
- 0.09% chance of exploitation in 30 days – higher than 0% 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 cannot reliably automate steps 1–4 of the kill chain
- Technical impact
- Total control over the software or total information disclosure
CISA SSVC assessment, 2026-10-16.
- Patch
- Available – fixed in f9b38a8fbfa07f1deaf7ee1eb38fa8b21ea13990, c381039ade2e161ab08c0eda73c4f8b9a7115928, ba21439302db9a82fe4edbed1e38a97271529421 +5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 24 Jun 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
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
Description
In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.
References
- git.kernel.org/stable/c/6564e9c7af7e1dc7bfe7f3093b728abe484d7630 (opens in a new tab)
- git.kernel.org/stable/c/1777ceac4bea5e568a5ad44b7f9bb219c1db21b6 (opens in a new tab)
- git.kernel.org/stable/c/8c6c691bf062dc0753a139a4ab8cb92a70fcf8f3 (opens in a new tab)
- git.kernel.org/stable/c/aa82a078f70f7ff88ba7d1017134e79d1ac140f2 (opens in a new tab)
- git.kernel.org/stable/c/ba21439302db9a82fe4edbed1e38a97271529421 (opens in a new tab)
- git.kernel.org/stable/c/f9b38a8fbfa07f1deaf7ee1eb38fa8b21ea13990 (opens in a new tab)
- git.kernel.org/stable/c/37487d55bf3300e3d2c1368da5c2bd3e3834ea4f (opens in a new tab)
- git.kernel.org/stable/c/c381039ade2e161ab08c0eda73c4f8b9a7115928 (opens in a new tab)