CVE-2026-80904
NoneCVSS
—
EPSS
0.2%
Published
Sep 4, 2026
CISA due date
—
Cloudanix analysis
A Linux kernel networking bug lets one way of reading encrypted network data ignore an error that other ways correctly catch, so a broken connection can keep delivering data it should have stopped.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Improper Input Validation
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Missing error check for async decrypt failure (ctx->async_wait.err) in tls_sw_splice_read() allows the function to continue returning decrypted records on a TLS connection that other read paths have already aborted via sk_err.
Why it matters to the business
Applications relying on splice() for high-performance TLS data transfer may silently process invalid or unauthenticated records, leading to application crashes, data corruption, or inconsistent connection state across processes.
How an attack unfolds
An attacker establishes a TLS session, forces an async decrypt failure (for example via network manipulation or crafted records), then triggers splice() reads; because the splice path ignores the persisted error, it continues delivering data that recvmsg() and read_sock() correctly reject.
How to fix it
Update the Linux kernel to a version containing the fix that adds the async_wait.err check inside tls_sw_splice_read() before returning data; apply the patch referenced in the commit that resolves the missing error propagation.
How to confirm the fix worked
Confirm the tls_sw_splice_read() implementation now reads async_wait.err under the reader lock and aborts identically to tls_sw_recvmsg() and tls_sw_read_sock(); test with a deliberately failed async decrypt followed by splice() to verify the connection is terminated.
Typical attack path
- Establish TLS connection with software decryption enabled
- Induce async decrypt failure to populate async_wait.err and sk_err
- Invoke splice() on the socket to bypass the error check present in other read paths
- Continue receiving records that should have terminated the connection
How to detect it
Review kernel logs for tls_err_abort or sk_err entries around TLS sockets; inspect application code paths that use splice() on TLS sockets for missing error checks after async decrypt failures; correlate with process activity invoking splice on AF_INET/AF_INET6 sockets using TLS.
What your security team should do
- Prioritize kernel updates for any system using kTLS software decryption and splice()
- Audit applications that combine TLS sockets with splice() for error-handling assumptions
- Monitor upstream stable branches for the backported fix within the next 30 days
The record
In the Linux kernel, the following vulnerability has been resolved: net/tls: Fail tls_sw_splice_read() after a failed async decrypt When an async decrypt fails, tls_decrypt_done() records the error in ctx->async_wait.err and calls tls_err_abort(), which stores it in sk_err. tls_sw_recvmsg() and tls_sw_read_sock() each read async_wait.err once they hold the reader lock and fail the call: a record that did not authenticate breaks the connection. tls_sw_splice_read() has no such check, and sk_err does not stand in for one. tls_rx_rec_wait() tests sk_err only inside the loop it skips whenever a record is already parsed, and the first reader to reach sock_error() clears it, while async_wait.err persists. A splice therefore keeps delivering records on a connection that recvmsg() and read_sock() refuse to read. Read async_wait.err in tls_sw_splice_read() as the other two readers do.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|