tls: always refresh the queue when reading sock
CVE: CVE-2025-38471
Component: kernel
CWE: CWE-416
Severity: Important
CVSS v3: 7.4/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H
Release date: 2025-07-28T00:00:00+00:00

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

tls: always refresh the queue when reading sock

After recent changes in net-next TCP compacts skbs much more
aggressively. This unearthed a bug in TLS where we may try
to operate on an old skb when checking if all skbs in the
queue have matching decrypt state and geometry.

    BUG: KASAN: slab-use-after-free in tls_strp_check_rcv+0x898/0x9a0 [tls]
    (net/tls/tls_strp.c:436 net/tls/tls_strp.c:530 net/tls/tls_strp.c:544)
    Read of size 4 at addr ffff888013085750 by task tls/13529

    CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme
    Call Trace:
     kasan_report+0xca/0x100
     tls_strp_check_rcv+0x898/0x9a0 [tls]
     tls_rx_rec_wait+0x2c9/0x8d0 [tls]
     tls_sw_recvmsg+0x40f/0x1aa0 [tls]
     inet_recvmsg+0x1c3/0x1f0

Always reload the queue, fast path is to have the record in the queue
when we wake, anyway (IOW the path going down "if !strp->stm.full_len").

Statement: This patch fixes a use-after-free bug in the kernel TLS (kTLS) implementation, where stale SKB pointers could be accessed due to aggressive TCP skb compaction.
The function tls_strp_read_sock() failed to reload the skb queue unconditionally, potentially leading to dereferencing freed memory in tls_strp_check_rcv().
This issue could be triggered remotely over a TCP+TLS connection and may result in kernel crashes or information disclosure.
While the bug requires precise timing and TCP skb compaction behavior, it may be remotely triggered through a TLS stream and can lead to kernel instability or data leakage from freed memory.
Although the underlying bug is a use-after-free read, it can lead to kernel panic on systems with KASAN, SLUB debug, panic_on_oops=1, or when the freed skb is reused and corrupted, potentially causing further memory violations or invalid state propagation in the TLS receive path.

Remediation:
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
To mitigate this issue, prevent module tls from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.