xfrm: espintcp: do not reuse an in-progress partial send
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.94, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
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.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 · fixed in 6564e9c7af7e1dc7bfe7f3093b728abe484d7630; From e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 · fixed in 1777ceac4bea5e568a5ad44b7f9bb219c1db21b6; From e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 · fixed in 8c6c691bf062dc0753a139a4ab8cb92a70fcf8f3; From e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 · fixed in aa82a078f70f7ff88ba7d1017134e79d1ac140f2; From e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 · fixed in ba21439302db9a82fe4edbed1e38a97271529421; From e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 · fixed in f9b38a8fbfa07f1deaf7ee1eb38fa8b21ea13990; From e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 · fixed in 37487d55bf3300e3d2c1368da5c2bd3e3834ea4f; From e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 · fixed in c381039ade2e161ab08c0eda73c4f8b9a7115928
- Linux Linux
5.6
- KernelLinux
From 5.6.0 · fixed in 5.10.259; From 5.11.0 · fixed in 5.15.210; From 5.16.0 · fixed in 6.1.176; From 6.2.0 · fixed in 6.6.143; From 6.7.0 · fixed in 6.12.94; From 6.13.0 · fixed in 6.18.36; From 6.19.0 · fixed in 7.0.13
References 8
git.kernel.org
- stable/c/6564e9c7af7e1dc7bfe7f3093b728abe484d7630
- stable/c/1777ceac4bea5e568a5ad44b7f9bb219c1db21b6
- stable/c/8c6c691bf062dc0753a139a4ab8cb92a70fcf8f3
- stable/c/aa82a078f70f7ff88ba7d1017134e79d1ac140f2
- stable/c/ba21439302db9a82fe4edbed1e38a97271529421
- stable/c/f9b38a8fbfa07f1deaf7ee1eb38fa8b21ea13990
- stable/c/37487d55bf3300e3d2c1368da5c2bd3e3834ea4f
- stable/c/c381039ade2e161ab08c0eda73c4f8b9a7115928