UBUNTU-CVE-2026-23414
In the Linux kernel, the following vulnerability has been resolved: tls: Purge async_hold in tls_decrypt_async_wait() The async_hold queue pins encrypted input skbs while the AEAD engine references their scatterlist data. Once tls_decrypt_async_wait() returns, every AEAD operation has completed and the engine no longer references those skbs, so they can be freed unconditionally. A subsequent patch adds batch async decryption to tls_sw_read_sock(), introducing a new call site that must drain pending AEAD operations and release held skbs. Move __skb_queue_purge(&ctx->async_hold) into tls_decrypt_async_wait() so the purge is centralized and every caller -- recvmsg's drain path, the -EBUSY fallback in tls_do_decryption(), and the new read_sock batch path -- releases held skbs on synchronization without each site managing the purge independently. This fixes a leak when tls_strp_msg_hold() fails part-way through, after having added some cloned skbs to the async_hold queue. tls_decrypt_sg() will then call tls_decrypt_async_wait() to process all pending decrypts, and drop back to synchronous mode, but tls_sw_recvmsg() only flushes the async_hold queue when one record has been processed in "fully-async" mode, which may not be the case here. [[email protected]: added leak comment]
02 / AFFECTED SOFTWARE
Affected packages
6 explicit affected versions
18 explicit affected versions
14 explicit affected versions
8 explicit affected versions
10 explicit affected versions
7 explicit affected versions
13 explicit affected versions
26 explicit affected versions
11 explicit affected versions
50 explicit affected versions
12 explicit affected versions
19 explicit affected versions
10 explicit affected versions
6 explicit affected versions
24 explicit affected versions
10 explicit affected versions
37 explicit affected versions
26 explicit affected versions
7 explicit affected versions
40 explicit affected versions
13 explicit affected versions
44 explicit affected versions
4 explicit affected versions
35 explicit affected versions
18 explicit affected versions
45 explicit affected versions
13 explicit affected versions
10 explicit affected versions
20 explicit affected versions
23 explicit affected versions
52 explicit affected versions
1 explicit affected versions
21 explicit affected versions
7 explicit affected versions
16 explicit affected versions
48 explicit affected versions
8 explicit affected versions
7 explicit affected versions
12 explicit affected versions
11 explicit affected versions
7 explicit affected versions
12 explicit affected versions
14 explicit affected versions
10 explicit affected versions
1 explicit affected versions
34 explicit affected versions
7 explicit affected versions
17 explicit affected versions
12 explicit affected versions
10 explicit affected versions
12 explicit affected versions
41 explicit affected versions
16 explicit affected versions
17 explicit affected versions
27 explicit affected versions
10 explicit affected versions
37 explicit affected versions
10 explicit affected versions
11 explicit affected versions
13 explicit affected versions
39 explicit affected versions
10 explicit affected versions
11 explicit affected versions
26 explicit affected versions
10 explicit affected versions
13 explicit affected versions
29 explicit affected versions
13 explicit affected versions
12 explicit affected versions
41 explicit affected versions
40 explicit affected versions
8 explicit affected versions
33 explicit affected versions
23 explicit affected versions
5 explicit affected versions
10 explicit affected versions
20 explicit affected versions
19 explicit affected versions
11 explicit affected versions
10 explicit affected versions
12 explicit affected versions
11 explicit affected versions
7 explicit affected versions
12 explicit affected versions
10 explicit affected versions
16 explicit affected versions
10 explicit affected versions
26 explicit affected versions
39 explicit affected versions
35 explicit affected versions
48 explicit affected versions
11 explicit affected versions
10 explicit affected versions
13 explicit affected versions
46 explicit affected versions
16 explicit affected versions
50 explicit affected versions
3 explicit affected versions
7 explicit affected versions
15 explicit affected versions
51 explicit affected versions
16 explicit affected versions
18 explicit affected versions
43 explicit affected versions
12 explicit affected versions
7 explicit affected versions
27 explicit affected versions
43 explicit affected versions
8 explicit affected versions
46 explicit affected versions
13 explicit affected versions
13 explicit affected versions
7 explicit affected versions
8 explicit affected versions
12 explicit affected versions
9 explicit affected versions
44 explicit affected versions
16 explicit affected versions
3 explicit affected versions
45 explicit affected versions
37 explicit affected versions
50 explicit affected versions
14 explicit affected versions
38 explicit affected versions
9 explicit affected versions
17 explicit affected versions
11 explicit affected versions
39 explicit affected versions
6 explicit affected versions
7 explicit affected versions
4 explicit affected versions
10 explicit affected versions
1 explicit affected versions
13 explicit affected versions
43 explicit affected versions
16 explicit affected versions
10 explicit affected versions
8 explicit affected versions
45 explicit affected versions
14 explicit affected versions
4 explicit affected versions
78 explicit affected versions
14 explicit affected versions
11 explicit affected versions
1 explicit affected versions
19 explicit affected versions
39 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
In the Linux kernel, the following vulnerability has been resolved: tls: Purge async_hold in tls_decrypt_async_wait() The async_hold queue pins encrypted input skbs while the AEAD engine references their scatterlist data. Once tls_decrypt_async_wait() returns, every AEAD operation has completed and the engine no longer references those skbs, so they can be freed unconditionally. A subsequent patch adds batch async decryption to tls_sw_read_sock(), introducing a new call site that must drain pending AEAD operations and release held skbs. Move __skb_queue_purge(&ctx->async_hold) into tls_decrypt_async_wait() so the purge is centralized and every caller -- recvmsg's drain path, the -EBUSY fallback in tls_do_decryption(), and the new read_sock batch path -- releases held skbs on synchronization without each site managing the purge independently. This fixes a leak when tls_strp_msg_hold() fails part-way through, after having added some cloned skbs to the async_hold queue. tls_decrypt_sg() will then call tls_decrypt_async_wait() to process all pending decrypts, and drop back to synchronous mode, but tls_sw_recvmsg() only flushes the async_hold queue when one record has been processed in "fully-async" mode, which may not be the case here. [[email protected]: added leak comment]
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/84a8335d8300576f1b377ae24abca1d9f197807f
- https://ubuntu.com/security/CVE-2026-23414
- https://ubuntu.com/security/notices/USN-8567-1
- https://ubuntu.com/security/notices/USN-8574-1
- https://ubuntu.com/security/notices/USN-8574-2
- https://ubuntu.com/security/notices/USN-8574-3
- https://ubuntu.com/security/notices/USN-8595-1
- https://ubuntu.com/security/notices/USN-8595-2
- https://ubuntu.com/security/notices/USN-8595-3
- https://ubuntu.com/security/notices/USN-8596-1
- https://ubuntu.com/security/notices/USN-8606-1
- https://ubuntu.com/security/notices/USN-8607-1
- https://ubuntu.com/security/notices/USN-8608-1
- https://ubuntu.com/security/notices/USN-8609-1
- https://ubuntu.com/security/notices/USN-8619-1
- https://www.cve.org/CVERecord?id=CVE-2026-23414