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]
| Vendor | Product | Versions |
|---|---|---|
| linux | linux kernel | c61d4368197d65c4809d9271f3b85325a600586a, 39dec4ea3daf77f684308576baf483b55ca7f160, b8a6ff84abbcbbc445463de58704686011edc8e1, b8a6ff84abbcbbc445463de58704686011edc8e1, b8a6ff84abbcbbc445463de58704686011edc8e1, 9f83fd0c179e0f458e824e417f9d5ad53443f685, 4fc109d0ab196bd943b7451276690fb6bb48c2e0, 6.18, 6.6.130, 6.12.79, 6.18.20, 6.19.10, 7.0-rc5 |
Updated severity to CRITICAL, added new affected versions, and noted no exploit available.
Initial creation
