В ядре Linux устранена следующая уязвимость:
tls: очистить async_hold в tls_decrypt_async_wait()
Очередь async_hold закрепляет зашифрованные входные skbs, пока
механизм AEAD ссылается на данные своего списка разброса. Однажды
tls_decrypt_async_wait() возвращает каждую операцию AEAD
завершено, и движок больше не ссылается на эти
skbs, поэтому их можно освободить безоговорочно. Следующий патч добавляет пакетное асинхронное расшифрование в
tls_sw_read_sock(), представляющий новый сайт вызова, который
должен истощить ожидающие операции AEAD и освободить удерживаемые
скбс.
Переместите __skb_queue_purge(&ctx->async_hold) в
tls_decrypt_async_wait(), чтобы очистка была централизованной.
и каждый вызывающий абонент — путь стока Recvmsg, -EBUSY
резервный вариант в tls_do_decryption() и новый read_sock
пакетный путь — освобождает удерживаемые skbs при синхронизации
без того, чтобы каждый объект управлял очисткой независимо. Это устраняет утечку, когда tls_strp_msg_hold() завершается сбоем на полпути,
после добавления нескольких клонированных skbs в async_hold
очередь. tls_decrypt_sg() затем вызовет tls_decrypt_async_wait() для
обработать все ожидающие расшифровки и вернуться в синхронный режим, но
tls_sw_recvmsg() очищает очередь async_hold только тогда, когда одна запись имеет
были обработаны в «полностью асинхронном» режиме, что в данном случае может быть не так.
[pabeni@redhat.com: добавлен комментарий об утечке]
Показать оригинальное описание (EN)
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]