Look up another CVE · open CVE-2026-74610 in the interactive tracker
CVE-2026-74610
tls: don't leave a full plaintext sk_msg ring unpushed
Published 2026-08-22 (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-74610 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 | fixedDSA-6466-1 · 2026-08-25 · text | 6.12.105-1 | Update the kernel and reboot. DSA-6466-1 shipped the fix on 2026-08-25, in 6.12.105-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.9-1 | Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.9-1 | Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4788-1 · 2026-09-19 · text | 6.12.107-1~deb12u1 | Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
When the copy path in tls_sw_sendmsg_locked() adds the fragment that fills the plaintext sk_msg ring, it does not set full_record, so the record is left full and unpushed. A later splice() then adds to an already full ring: sk_msg_page_add() has no fullness check of its own, so sg.end wraps onto sg.start and the ring appears empty. Fragments added after that overwrite live entries, and sg.size no longer matches what is reachable between sg.start and sg.end, so pushing the record runs the scatterwalk off the end of the scatterlist. An unprivileged user can trigger this on a loopback TCP socket with the "tls" ULP attached: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:memcpy_from_scatterwalk+0x32/0xc0 Call Trace: skcipher_walk_next+0x1d1/0x2c0 gcm_encrypt_aesni_avx+0x1e9/0x220 bpf_exec_tx_verdict+0x3bb/0x860 tls_sw_sendmsg+0xa1a/0xca0 __sys_sendto+0x1da/0x1f0 Set full_record in the copy path when the ring becomes full, and push a record that is already full on entry to the sendmsg loop.
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, sid, bookworm · linux-6.12m
- 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-22 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.2% 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.5 | 6.6.152 | aa8b14647721 |
| 6.5 | 6.12.104 | f634289a0b55 |
| 6.5 | 6.18.45 | 3fc5044796dd |
| 6.5 | 7.1.9 | 3c5f8f2aa57c |
| 6.5 | 7.2 | 7bca91d63341 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4788-1 | 2026-09-19 | bookworm 6.12.107-1~deb12u1 | tracker |
| DSA-6466-1 | 2026-08-25 | trixie 6.12.105-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:LAttack vector, local
- The bug is reached from tls_sw_sendmsg() via local sendmsg/sendto/splice syscalls on a TCP socket with the tls ULP; the copy-then-splice sequence is driven by the sending process (commit repro: unprivileged user on loopback), not by remote TLS ciphertext on RX.
- AC:LAttack complexity, low
- An attacker fully controls the vulnerable send path by crafting alternating copy and MSG_SPLICE_PAGES splice sequences on their kTLS socket until the plaintext sk_msg ring fills without full_record then wraps; no privileged races or special memory layout are required.
- PR:LPrivileges required, low
- Any unprivileged local user can create a TCP socket, attach the tls ULP with TCP_ULP and SOL_TLS setsockopt (no capability checks in net/tls), and trigger the bug with sendmsg/splice as demonstrated on loopback.
- UI:NUser interaction, none
- Exploitation requires only the attacker's own socket I/O to sequence copy and splice operations; no action by another user or administrator is needed.
- S:UScope, unchanged
- Memory corruption occurs within kernel TLS/sk_msg state of the attacking process's connection context; there is no crossing of VM, container, or IOMMU security boundaries beyond ordinary kernel compromise.
- C:HConfidentiality impact, high
- Corrupting a full sk_msg ring overwrites live scatterlist entries and desynchronizes sg.size from reachable fragments, so tls_push_record/AEAD scatterwalk can read past the scatterlist end; this class of kernel heap corruption is exploitable for arbitrary memory disclosure beyond the observed NULL deref.
- I:HIntegrity impact, high
- The wrap corrupts scatterlist metadata and drives out-of-bounds scatterwalk during GCM encryption, giving attacker-influenced overwrite primitives on kernel heap objects adjacent to sk_msg data, enabling control-flow hijack beyond the demonstrated crash.
- A:HAvailability impact, high
- Pushing a corrupted record runs the AEAD scatterwalk off the scatterlist end, producing a kernel NULL pointer dereference in memcpy_from_scatterwalk during gcm_encrypt and crashing the host (commit oops trace).