Repository navigation
[ciqlts8_6] Multiple patches tested (2 commits) - #1695
ciq-kernel-automation[bot] wants to merge 2 commits into
Conversation
jira VULN-189080 cve CVE-2026-52935 commit-author Wyatt Feng <bronzed_45_vested@icloud.com> commit c381039 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. Fixes: e27cca9 ("xfrm: add espintcp (RFC 8229)") Cc: stable@kernel.org Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Zhengchuan Liang <zcliangcn@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Assisted-by: Codex:GPT-5.4 Signed-off-by: Wyatt Feng <bronzed_45_vested@icloud.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> (cherry picked from commit c381039) Signed-off-by: Hailey Mothershead <hmothershead@ciq.com>
jira VULN-217148 cve CVE-2026-80848 commit-author Sabrina Dubroca <sd@queasysnail.net> commit deb232e ZDI reported and analyzed a race condition during close for espintcp sockets: espintcp_close() frees emsg->skb via kfree_skb() without holding any socket lock. Concurrently, the xfrm_trans_reinject work queue invokes esp_output_tcp_finish() -> espintcp_push_skb() -> espintcp_push_msgs() -> skb_send_sock_locked(), which reads the same skb as a data source. Fix this by adding a synchronize_rcu() call after resetting sk_prot, since esp_output_tcp_finish() runs under RCU and won't use a socket with sk_prot == &tcp_prot. Simply taking the socket lock in espintcp_close() could lead to leaks, if esp_output_tcp_finish() re-adds an skb in the slot we just freed. After this, the existing barrier() is no longer needed. Cc: stable@vger.kernel.org Fixes: e27cca9 ("xfrm: add espintcp (RFC 8229)") Reported-by: zdi-disclosures@trendmicro.com Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Reviewed-by: Breno Leitao <leitao@debian.org> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> (cherry picked from commit deb232e) Signed-off-by: Hailey Mothershead <hmothershead@ciq.com>
ciq-kernel-automation
Bot
added
the
created-by-kernelci
|
🤖 Validation Checks In Progress Workflow run: https://github.com/ctrliq/kernel-src-tree/actions/runs/38537815836 |
🔍 Diffofdiffs: 1 of 2 backports differs from upstreamOpen to anyone signed in to GitHub. Report expires 2027-01-12 08:40 UTC.
Checked PR revision |
|
✅ Validation checks completed successfully View full results: https://github.com/ctrliq/kernel-src-tree/actions/runs/38537815836 |
bmastbergen
left a comment
bmastbergen
left a comment
There was a problem hiding this comment.
Same issue as PR 1694
I had GLM take a look at this and it flagged a missing prerequisite for the UAF fix.
That fix's safety rests on the premise that esp_output_tcp_finish() runs under RCU and won't use a socket once sk->sk_prot == &tcp_prot. But synchronize_rcu() only drains readers already inside an RCU section. Readers that start AFTER the grace period are stopped only by the sk_prot check.
On this tree, esp_find_tcp_sk()/esp6_find_tcp_sk() still have the x->encap_sk cached fast path (esp4.c:145 / esp6.c:161):
sk = rcu_dereference(x->encap_sk);
if (sk && sk->sk_state == TCP_ESTABLISHED)
return sk;
which returns the socket without the sk_prot check. Between the sk_prot reset and tcp_close() at the end of espintcp_close(), sk_state is still TCP_ESTABLISHED, so a reinject worker starting after the grace period takes this fast path, reaches espintcp_push_skb(), and reads emsg->skb concurrently with the kfree_skb() in close which is the same UAF the CVE describes.
Suggest picking up 0283636 as a prereq which removes the fast path completely and is itself associated with CVE-2025-38097.
We could also add 63c1f19 to fix an error path skb leak that exists in the tree today, and is somewhat exacerbated by adding the prereq + UAF fix.
3 participants
Summary
This PR has been automatically created after successful completion of all CI stages.
Commit Message(s)
Test Results
✅ Build Stage
✅ Boot Verification
✅ Kernel Selftests
✅ LTP Results
🤖 This PR was automatically generated by GitHub Actions
Run ID: 38513358462