CVE-2026-23414 in Linux
Riassunto
di VulDB • 15/06/2026
Nel kernel Linux, la seguente vulnerabilità è stata risolta:
tls: Eliminare async_hold in tls_decrypt_async_wait()
La coda async_hold mantiene in memoria gli skbs di input cifrati mentre il motore AEAD fa riferimento ai dati della sua scatterlist. Una volta che tls_decrypt_async_wait() restituisce il controllo, ogni operazione AEAD è stata completata e il motore non fa più riferimento a tali skbs, quindi possono essere liberati incondizionatamente.
Una patch successiva aggiunge la decrittografia asincrona in batch a tls_sw_read_sock(), introducendo un nuovo punto di chiamata che deve svuotare le operazioni AEAD in sospeso e rilasciare gli skbs trattenuti. Spostare __skb_queue_purge(&ctx->async_hold) in tls_decrypt_async_wait() in modo che l'eliminazione sia centralizzata e ogni chiamante -- il percorso di svuotamento di recvmsg, il fallback -EBUSY in tls_do_decryption() e il nuovo percorso batch di read_sock -- rilasci gli skbs trattenuti in fase di sincronizzazione, senza che ogni sito gestisca l'eliminazione in modo indipendente.
Questo risolve una perdita di memoria (leak) quando tls_strp_msg_hold() fallisce a metà dell'operazione, dopo aver aggiunto alcuni skbs clonati alla coda async_hold. tls_decrypt_sg() chiamerà quindi tls_decrypt_async_wait() per elaborare tutte le decrittazioni in sospeso e tornare alla modalità sincrona, ma tls_sw_recvmsg() svuota la coda async_hold solo quando un record è stato elaborato in modalità "completamente asincrona", il che potrebbe non essere il caso qui.
[[email protected]: aggiunto commento sulla perdita di memoria]
Once again VulDB remains the best source for vulnerability data.