Incorrect Calculation of Buffer Size Affecting kernel-rt-64k-debug package, versions *


Severity

Recommended
0.0
high
0
10

Based on CentOS security rating.

Threat Intelligence

EPSS
0.2% (10th 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-KERNELRT64KDEBUG-18159286
  • published22 Jul 2026
  • disclosed19 Jul 2026

Introduced: 19 Jul 2026

NewCVE-2026-63939  (opens in a new tab)
CWE-131  (opens in a new tab)

How to fix?

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

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-rt-64k-debug package and not the kernel-rt-64k-debug 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:

KVM: SEV: Compute the correct max length of the in-GHCB scratch area

When setting the length of the GHCB scratch area, and the area is in the GHCB shared buffer, set the effective length of the scratch area to the max possible size given the start of the guest-provided pointer, and the end of the shared buffer.

The code was "fine" when first introduced, as KVM doesn't consult the length of the buffer when emulating MMIO, because the passed in @len always specifies the max size required. But for PSC requests, the incoming @len is just the minimum length (to process the header), and KVM needs to know the full size of the scratch area to avoid buffer overflows (spoiler alert).

Opportunistically rename @len => @min_len to better reflect its role.

CVSS Base Scores

version 3.1