Look up another CVE · open CVE-2026-72330 in the interactive tracker
CVE-2026-72330
net/tls: Consume empty data records in tls_sw_read_sock()
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem net/tls. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-72330 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
A peer may send a zero-length TLS application_data record; TLS 1.3 explicitly permits these as a traffic-analysis countermeasure (RFC 8446, Section 5.1). After decryption such a record has full_len == 0. tls_sw_read_sock() hands it to the read_actor, which has no payload to consume and returns zero. The loop treats a zero return as backpressure (used <= 0), requeues the skb at the head of rx_list, and stops. rx_list is serviced head-first on the next call, so the empty record is dequeued, fails the same way, and is requeued again; every later record on the connection is blocked behind it. tls_sw_recvmsg() does not stall on this: a zero-length data record copies nothing and falls through to consume_skb(). Mirror that in the read_sock() path by recognizing an empty data record before the actor runs, consuming it, and continuing.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/tls/tls_sw.c
- What this is
- NETWORKING [TLS]MAINTAINERS section matched on net/tls/ · netdev@vger.kernel.org · Maintained
- Kernel module
- tls
Check it on the machine
grep -w CONFIG_TLS /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w tlsPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_TLS
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.62%, higher than 48.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- net/tls
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.6 | 6.6.145 | 0867b0f2513e |
| 6.6 | 6.12.97 | c6b440cf766a |
| 6.6 | 6.18.40 | e8a4c9fc437b |
| 6.6 | 7.1.5 | ebc295ce3436 |
| 6.6 | 7.2 | 3be28e2c9cd0 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- A remote TLS peer sends zero-length TLS 1.3 application_data records over TCP; they are decrypted in the kTLS software RX path and processed in tls_sw_read_sock(), reachable from network-facing consumers such as NVMe-over-TCP host I/O via sock->ops->read_sock.
- AC:LAttack complexity, low
- After a normal TLS handshake, sending a standards-compliant zero-length application_data record reliably reproduces the stall; no races, special memory layout, or rare timing are required.
- PR:NPrivileges required, none
- Exploitation requires only being the remote TLS peer on an established kTLS connection (e.g. a malicious NVMe-oF target); no local account, capability, namespace, or administrator privileges on the victim host are needed.
- UI:NUser interaction, none
- No victim user action beyond the system maintaining its normal encrypted network connection; the attacker triggers the flaw by sending protocol-valid TLS records.
- S:UScope, unchanged
- Impact is confined to stalling the affected TLS/kTLS connection and its dependent service I/O; it does not cross a security boundary such as guest-to-host escape or sandbox breakout.
- C:NConfidentiality impact, none
- The flaw is a receive-path logic error that requeues an empty skb indefinitely; there is no out-of-bounds access, use-after-free, or other memory corruption that could disclose kernel or application data.
- I:NIntegrity impact, none
- The bug does not modify kernel memory, credentials, or application data; it only prevents forward progress on the stalled connection by blocking consumption of subsequent decrypted records.
- A:HAvailability impact, high
- The empty record is permanently requeued at the head of rx_list, creating a repeatable deadlock that blocks all later traffic on the connection and can hang NVMe-over-TCP (or similar read_sock) I/O until the connection is torn down.