CVE-2026-80852: Linux Kernel TLS Buffer Overflow Vulnerability

CVE-2026-80852 Overview

CVE-2026-80852 is an out-of-bounds write vulnerability in the Linux kernel's TLS device offload path, specifically in the tls_append_frag() function within net/tls/tls_device.c. The flaw was discovered using syzkaller against a local syzbot instance running on top of a netdevsim TLS offload emulation. When TLS_TX_ZEROCOPY_RO is enabled, repeated splice() calls with SPLICE_F_MORE can push the fragment count of an open TLS record past MAX_SKB_FRAGS. The resulting out-of-bounds writes corrupt adjacent memory, including the destruct_work structure that follows the scatter-gather array, leading to kernel memory corruption and controlled function pointer overwrite when the workqueue later executes.

Critical Impact
A local unprivileged process can trigger kernel out-of-bounds writes that corrupt workqueue function pointers, resulting in kernel crash or potential privilege escalation on systems using TLS device offload.

Affected Products

Linux kernel with TLS device offload (CONFIG_TLS_DEVICE) enabled
Systems with network interface cards implementing TLS offload
Kernels prior to the fixes in commits 03ced5d, 7e1208c, a832d7c, b17cf74, b7f10d4, cd7e875, and fadbc1e

Discovery Timeline

2026-09-04 - CVE-2026-80852 published to NVD
2026-09-04 - Last updated in NVD database

Technical Details for CVE-2026-80852

Vulnerability Analysis

The vulnerability is an out-of-bounds write [CWE-787] in the Linux kernel TLS device offload subsystem. The function tls_push_data() only validates whether the currently open TLS record has room for another fragment at the bottom of its main loop. When the caller passes MSG_MORE, the early break skips this fragment-count check. The record persists across syscalls with its existing fragment count intact, and tls_append_frag() performs no bounds validation of its own.

With TLS_TX_ZEROCOPY_RO enabled, each splice() call using SPLICE_F_MORE for even a single byte adds a non-coalescing pipe page to the record. The num_frags counter walks past the end of tls_record_info.frags[MAX_SKB_FRAGS] (where MAX_SKB_FRAGS is 17). When the record is finally pushed, tls_push_record() iterates the same overflowed index across sg_tx_data[MAX_SKB_FRAGS], and sg_set_page() writes into the destruct_work structure that immediately follows. The kernel workqueue subsequently dereferences the corrupted function pointer.

Root Cause

The root cause is missing bounds validation on the fragment count in the MSG_MORE code path of tls_push_data(). The byte-limit check works because the copy length decrements to zero and the loop falls through to the shared check. The fragment count has no such feedback loop, allowing unbounded growth across successive syscalls.

Attack Vector

An attacker with local access to a socket configured with kernel TLS (kTLS) offload and TLS_TX_ZEROCOPY_RO can issue repeated splice() operations with SPLICE_F_MORE, each transferring one or two bytes. Each call increments the fragment count without pushing the record. After exhausting MAX_SKB_FRAGS slots, subsequent writes land in the destruct_work structure. When the record is eventually pushed, the corrupted function pointer is invoked by the ktls_device_destruct workqueue, as demonstrated by the reported crash executing at address 0xffffea000411a680.

The upstream fix aligns TLS behavior with plain TCP by pushing the record when it is full rather than keeping it open across MSG_MORE boundaries, mirroring how tcp_sendmsg_locked() calls tcp_mark_push() and starts a new segment.

Detection Methods for CVE-2026-80852

Indicators of Compromise

KASAN reports citing slab-out-of-bounds in tls_append_frag at net/tls/tls_device.c:269
UBSAN warnings for array-index-out-of-bounds in net/tls/tls_device.c around lines 300-307 referencing skb_frag_t [17] or scatterlist [17]
Kernel oops messages naming ktls_device_destruct in the workqueue call trace
Page fault entries reporting supervisor instruction fetch on non-canonical or NX-protected addresses following TLS socket activity

Detection Strategies

Enable KASAN and UBSAN in test and staging kernels to surface the memory corruption at the source rather than at the point of crash
Audit kernel builds for CONFIG_TLS_DEVICE=y combined with NICs advertising TLS transmit offload capability
Monitor for unexpected kernel panics or WARN traces referencing tls_push_data, tls_append_frag, or tls_push_record in production logs

Monitoring Recommendations

Ingest kernel ring buffer (dmesg) and journald output into a centralized log platform and alert on strings matching tls_append_frag, KASAN, UBSAN, or ktls_device_destruct
Correlate kernel oops events with local process activity to identify workloads exercising TLS offload paths
Track ethtool -k output across the fleet to inventory interfaces where tls-hw-tx-offload is active

How to Mitigate CVE-2026-80852

Immediate Actions Required

Apply the upstream Linux kernel patches referenced by commits 03ced5d, 7e1208c, a832d7c, b17cf74, b7f10d4, cd7e875, and fadbc1e from the stable trees
Consume the fixed kernel package from your distribution vendor once available and reboot affected hosts
Where patching is not immediately possible, disable TLS transmit offload on affected network interfaces

Patch Information

The fix has been merged across multiple stable branches. Refer to the upstream commits: Kernel Commit 03ced5d, Kernel Commit 7e1208c, Kernel Commit a832d7c, Kernel Commit b17cf74, Kernel Commit b7f10d4, Kernel Commit cd7e875, and Kernel Commit fadbc1e. The fix forces the record to be pushed when full instead of keeping it open across MSG_MORE invocations.

Workarounds

Disable TLS transmit offload on affected NICs using ethtool -K <iface> tls-hw-tx-offload off
Build kernels without CONFIG_TLS_DEVICE where hardware TLS offload is not required
Restrict local user access on systems where TLS offload cannot be disabled, reducing exposure to unprivileged triggers

bash

# Disable TLS transmit hardware offload on the affected interface
sudo ethtool -K eth0 tls-hw-tx-offload off

# Verify the offload is disabled
ethtool -k eth0 | grep tls

# Confirm the running kernel version incorporates the fix
uname -r