CVE-2026-80904 in Linux
Summary
by MITRE • 09/04/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel's TLS implementation contains a critical inconsistency in error handling logic within the network stack, specifically affecting how asynchronous decryption failures are propagated across different socket reading interfaces. This vulnerability arises from a divergence in behavior between standard read operations and splice-based data retrieval mechanisms. When an asynchronous decryption operation fails due to authentication errors or other cryptographic issues, the kernel correctly records this failure state by storing the error code in the context's async_wait.err field and invoking tls_err_abort(). This function subsequently updates the socket's general error status via sk_err, signaling that a record failed to authenticate and thus breaking the connection integrity. The standard read paths, implemented through functions like tls_sw_recvmsg() and tls_sw_read_sock(), are designed to respect this failure state by checking async_wait.err after acquiring the necessary reader locks, thereby ensuring that corrupted or unauthenticated data is not delivered to user-space applications.
However, the splice interface, handled by tls_sw_splice_read(), lacks this crucial validation step. While it correctly interacts with the underlying socket infrastructure, it fails to inspect the async_wait.err field before proceeding with data transfer. This oversight creates a significant security and reliability gap where the connection state is effectively ignored for specific types of I/O operations. The existing logic within tls_rx_rec_wait() attempts to check sk_err but only does so inside a loop that may be skipped if records are already parsed, leaving a window where error conditions are not properly enforced. Furthermore, because sock_error() can clear sk_err when the first reader processes it, relying solely on this flag is unreliable for subsequent readers or different I/O paths. Consequently, tls_sw_splice_read() continues to deliver data records even after an async decryption failure has been recorded, allowing potentially unauthenticated or malformed data to bypass standard security checks.
The operational impact of this vulnerability is severe, as it undermines the integrity guarantees provided by TLS encryption and authentication. An attacker who can trigger a decryption failure, such as through crafted malicious packets that cause authentication errors, could exploit this inconsistency to inject unauthorized data into an application using splice-based I/O. This bypasses the expected connection termination behavior, potentially leading to data corruption, information leakage, or further exploitation depending on how the receiving application processes the unauthenticated stream. The discrepancy between different read methods creates a confusing and dangerous state where some parts of the system correctly refuse broken connections while others continue processing invalid data, violating the principle of consistent security enforcement across all access paths.
To mitigate this vulnerability, it is essential to align the error handling logic in tls_sw_splice_read() with that of tls_sw_recvmsg() and tls_sw_read_sock(). The fix involves explicitly checking async_wait.err within splice_read operations after acquiring appropriate locks, ensuring that any recorded decryption failure immediately halts data delivery. This change restores consistency across all socket read interfaces and ensures that the connection is properly terminated upon authentication failures regardless of the I/O method used. From a classification perspective, this issue represents an improper check before performing security-critical actions, aligning with CWE-253: Incorrect Check of Function Return Value or CWE-704: Incorrect Type Conversion or Cast if viewed broadly as a logic error in state management. In terms of the MITRE ATT&CK framework, this flaw could facilitate techniques related to Defense Evasion by allowing malicious payloads to bypass integrity checks that would normally terminate the session, highlighting the importance of uniform validation across all data retrieval pathways in network stacks.