Bug 2492098 (CVE-2026-52935) - CVE-2026-52935 kernel: xfrm: espintcp: do not reuse an in-progress partial send
Summary: CVE-2026-52935 kernel: xfrm: espintcp: do not reuse an in-progress partial send
Keywords:
Status: NEW
Alias: CVE-2026-52935
Product: Security Response
Classification: Other
Component: vulnerability-draft
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-06-24 08:01 UTC by OSIDB Bzimport
Modified: 2026-10-29 14:23 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2026:85321 0 None None None 2026-10-19 21:46:55 UTC
Red Hat Product Errata RHSA-2026:85773 0 None None None 2026-10-20 03:51:53 UTC
Red Hat Product Errata RHSA-2026:85774 0 None None None 2026-10-20 03:42:40 UTC
Red Hat Product Errata RHSA-2026:86033 0 None None None 2026-10-20 20:31:09 UTC

Description OSIDB Bzimport 2026-06-24 08:01:54 UTC
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.

Comment 1 Mauro Matteo Cascella 2026-06-24 10:47:54 UTC
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026062433-CVE-2026-52935-7909@gregkh/T

Comment 7 Jon Orris 2026-10-19 21:46:54 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10

Via RHSA-2026:85321 https://access.redhat.com/errata/RHSA-2026:85321

Comment 8 Jon Orris 2026-10-20 03:42:39 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2026:85774 https://access.redhat.com/errata/RHSA-2026:85774

Comment 9 Jon Orris 2026-10-20 03:51:52 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2026:85773 https://access.redhat.com/errata/RHSA-2026:85773

Comment 10 Jon Orris 2026-10-20 20:31:08 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2026:86033 https://access.redhat.com/errata/RHSA-2026:86033


Note You need to log in before you can comment on or make changes to this bug.