Out-of-bounds Read Affecting kernel-rt-debug-kvm package, versions *


Severity

Recommended
medium

Based on CentOS security rating.

Threat Intelligence

EPSS
0.16% (6th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-CENTOS10-KERNELRTDEBUGKVM-17447680
  • published25 Jun 2026
  • disclosed24 Jun 2026

Introduced: 24 Jun 2026

NewCVE-2026-52935  (opens in a new tab)
CWE-125  (opens in a new tab)

How to fix?

There is no fixed version for Centos:10 kernel-rt-debug-kvm.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-rt-debug-kvm package and not the kernel-rt-debug-kvm package as distributed by Centos. See How to fix? for Centos:10 relevant fixed versions and status.

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.

CVSS Base Scores

version 3.1