tls: Purge async_hold in tls_decrypt_async_wait()
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 6.1.168, 6.6.131, 6.12.80, 6.18, 6.18.21, and 1 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: partial
Summary
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. [pabeni@redhat.com: added leak comment]
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- Linux Linux
From 9f83fd0c179e0f458e824e417f9d5ad53443f685 · fixed in ac435be7c7613eb13a5a8ceb5182e10b50c9ce87; From c61d4368197d65c4809d9271f3b85325a600586a · fixed in 2dcf324855c34e7f934ce978aa19b645a8f3ee71; From 39dec4ea3daf77f684308576baf483b55ca7f160 · fixed in 6dc11e0bd0a5466bcc76d275c09e5537bd0597dd; From b8a6ff84abbcbbc445463de58704686011edc8e1 · fixed in 9f557c7eae127b44d2e863917dc986a4b6cb1269; From b8a6ff84abbcbbc445463de58704686011edc8e1 · fixed in fd8037e1f18ca5336934d0e0e7e1a4fe097e749d; From b8a6ff84abbcbbc445463de58704686011edc8e1 · fixed in 84a8335d8300576f1b377ae24abca1d9f197807f; From 6.1.158 · fixed in 6.1.168; From 6.6.114 · fixed in 6.6.131; From 6.12.55 · fixed in 6.12.80; From 6.17.5 · fixed in 6.18
- Linux Linux
6.18
- KernelLinux
fixed in 6.1.168; From 6.2.0 · fixed in 6.6.131; From 6.7.0 · fixed in 6.12.80; From 6.13.0 · fixed in 6.18.21; From 6.18.0 · fixed in 6.19.11