linux-cve-announce - CVE-2025-38616: tls: handle data disappearing from under the TLS ULP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2025082212-CVE-2025-38616-64a8@gregkh>
Date: Fri, 22 Aug 2025 15:01:12 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-38616: tls: handle data disappearing from under the TLS ULP

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

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

tls: handle data disappearing from under the TLS ULP

TLS expects that it owns the receive queue of the TCP socket.
This cannot be guaranteed in case the reader of the TCP socket
entered before the TLS ULP was installed, or uses some non-standard
read API (eg. zerocopy ones). Replace the WARN_ON() and a buggy
early exit (which leaves anchor pointing to a freed skb) with real
error handling. Wipe the parsing state and tell the reader to retry.

We already reload the anchor every time we (re)acquire the socket lock,
so the only condition we need to avoid is an out of bounds read
(not having enough bytes in the socket for previously parsed record len).

If some data was read from under TLS but there's enough in the queue
we'll reload and decrypt what is most likely not a valid TLS record.
Leading to some undefined behavior from TLS perspective (corrupting
a stream? missing an alert? missing an attack?) but no kernel crash
should take place.

The Linux kernel CVE team has assigned CVE-2025-38616 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 6.0 with commit 84c61fe1a75b4255df1e1e7c054c9e6d048da417 and fixed in 6.12.43 with commit eb0336f213fe88bbdb7d2b19c9c9ec19245a3155
	Issue introduced in 6.0 with commit 84c61fe1a75b4255df1e1e7c054c9e6d048da417 and fixed in 6.15.11 with commit db3658a12d5ec4db7185ae7476151a50521b7207
	Issue introduced in 6.0 with commit 84c61fe1a75b4255df1e1e7c054c9e6d048da417 and fixed in 6.16.2 with commit 2fb97ed9e2672b4f6e24ce206ac1a875ce4bcb38
	Issue introduced in 6.0 with commit 84c61fe1a75b4255df1e1e7c054c9e6d048da417 and fixed in 6.17-rc2 with commit 6db015fc4b5d5f63a64a193f65d98da3a7fc811d

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-38616
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	net/tls/tls.h
	net/tls/tls_strp.c
	net/tls/tls_sw.c

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/eb0336f213fe88bbdb7d2b19c9c9ec19245a3155
	https://git.kernel.org/stable/c/db3658a12d5ec4db7185ae7476151a50521b7207
	https://git.kernel.org/stable/c/2fb97ed9e2672b4f6e24ce206ac1a875ce4bcb38
	https://git.kernel.org/stable/c/6db015fc4b5d5f63a64a193f65d98da3a7fc811d