Incorrect Calculation of Buffer Size Affecting kernel-devel-matched package, versions *


Severity

Recommended
medium

Based on CentOS security rating.

Threat Intelligence

EPSS
0.02% (5th 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-CENTOS9-KERNELDEVELMATCHED-16267863
  • published25 Apr 2026
  • disclosed24 Apr 2026

Introduced: 24 Apr 2026

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

How to fix?

There is no fixed version for Centos:9 kernel-devel-matched.

NVD Description

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

In the Linux kernel, the following vulnerability has been resolved:

rxrpc: proc: size address buffers for %pISpc output

The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with "%pISpc".

That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap().

As a result, a case such as

is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c.

Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf().

Changes since v1:

  • correct the changelog to cite the actual maximum current-tree case explicitly
  • frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example

CVSS Base Scores

version 3.1