Look up another CVE · open CVE-2026-52974 in the interactive tracker
CVE-2026-52974
net: tls: fix strparser anchor skb leak on offload RX setup failure
Published 2026-06-24 (4 months ago) by the Linux kernel CNA. Subsystem net/tls. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-52974 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 | fixedDLA-4665-1 · 2026-07-03 · text | 6.1.176-1 | Update the kernel and reboot. DLA-4665-1 shipped the fix on 2026-07-03, in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.10-1 | Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.10-1 | Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
When tls_set_device_offload_rx() fails at tls_dev_add(), the error path calls tls_sw_free_resources_rx() to clean up the SW context that was initialized by tls_set_sw_offload(). This function calls tls_sw_release_resources_rx() (which stops the strparser via tls_strp_stop()) and tls_sw_free_ctx_rx() (which kfrees the context), but never frees the anchor skb that was allocated by alloc_skb(0) in tls_strp_init(). Note that tls_sw_free_resources_rx() is exclusively used for this "failed to start offload" code path, there's no other caller. The leak did not exist before commit 84c61fe1a75b ("tls: rx: do not use the standard strparser"), because the standard strparser doesn't try to pre-allocate an skb. The normal close path in tls_sk_proto_close() handles cleanup by calling tls_sw_strparser_done() (which calls tls_strp_done()) after dropping the socket lock, because tls_strp_done() does cancel_work_sync() and the strparser work handler takes the socket lock.
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.h
net/tls/tls_strp.c
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-06-24 (4 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.50%, higher than 41.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- 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.0 | 6.1.175 | 0c9f399b37ce |
| 6.0 | 6.6.141 | 688f12aa4451 |
| 6.0 | 6.12.91 | 3c405dfa9619 |
| 6.0 | 6.18.33 | 9c54e76f8d6e |
| 6.0 | 7.0.10 | bd07fe6c38b9 |
| 6.0 | 7.1 | 58689498ca33 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4671-1 | 2026-07-05 | bullseye 6.1.176-1~deb11u1 | tracker |
| DLA-4665-1 | 2026-07-03 | bookworm 6.1.176-1 | tracker |
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 can plausibly trigger this through a network-facing kTLS-enabled service that installs TLS_RX state after handshake on a TLS RX offload-capable NIC. The direct kernel path is setsockopt-driven, but the vulnerable subsystem is kTLS receive/offload setup for network connections and can be reached per remote connection.
- AC:LAttack complexity, low
- There is no race or fragile timing requirement; the attacker can repeatedly drive RX state setup and can plausibly force tls_dev_add() failure via unsupported TLS 1.2 RX offload parameters or exhausted offload resources. The required offload-capable deployment is a reasonable server scenario for this subsystem.
- PR:NPrivileges required, none
- In the network-facing kTLS service scenario, the attacker needs no local account or prior authentication to initiate TLS connections that cause the service to install RX state. Any application-level authentication would occur after the connection setup path.
- UI:NUser interaction, none
- No victim user action is required beyond the target service automatically handling incoming TLS connections. The attacker can repeat the trigger by opening connections.
- S:UScope, unchanged
- The impact remains within the kernel and network stack security authority. There is no VM escape, IOMMU bypass, or cross-scope boundary crossing.
- C:NConfidentiality impact, none
- The bug leaks an internal zero-length anchor skb object by losing its reference; it does not expose kernel memory contents to the attacker. No read primitive or information disclosure was identified.
- I:NIntegrity impact, none
- The issue is a missing cleanup in an error path and does not corrupt memory or modify attacker-chosen kernel data. No write primitive or control-flow impact was identified.
- A:HAvailability impact, high
- The leaked skb is kernel memory and the failing offload setup path can be triggered repeatedly, allowing unbounded memory consumption. Related strparser skb leak precedent treats repeatable network-triggered memory exhaustion as high availability impact.