Improper Update of Reference Count 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-CENTOS10-KERNELDEVELMATCHED-15895595
  • published5 Apr 2026
  • disclosed2 Apr 2026

Introduced: 2 Apr 2026

NewCVE-2026-23414  (opens in a new tab)
CWE-911  (opens in a new tab)

How to fix?

There is no fixed version for Centos:10 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:10 relevant fixed versions and status.

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

tls: Purge async_hold in tls_decrypt_async_wait()

The async_hold queue pins encrypted input skbs while the AEAD engine references their scatterlist data. Once tls_decrypt_async_wait() returns, every AEAD operation has completed and the engine no longer references those skbs, so they can be freed unconditionally.

A subsequent patch adds batch async decryption to tls_sw_read_sock(), introducing a new call site that must drain pending AEAD operations and release held skbs. Move __skb_queue_purge(&ctx->async_hold) into tls_decrypt_async_wait() so the purge is centralized and every caller -- recvmsg's drain path, the -EBUSY fallback in tls_do_decryption(), and the new read_sock batch path -- releases held skbs on synchronization without each site managing the purge independently.

This fixes a leak when tls_strp_msg_hold() fails part-way through, after having added some cloned skbs to the async_hold queue. tls_decrypt_sg() will then call tls_decrypt_async_wait() to process all pending decrypts, and drop back to synchronous mode, but tls_sw_recvmsg() only flushes the async_hold queue when one record has been processed in "fully-async" mode, which may not be the case here.

[pabeni@redhat.com: added leak comment]

CVSS Base Scores

version 3.1