[PATCH] tls: fix encrypt_pending refcount leak on -EBUSY error path

[PATCH] tls: fix encrypt_pending refcount leak on -EBUSY error path

[WenTao Liang]

In tls_do_encryption(), when crypto_aead_encrypt() returns -EBUSY,
tls_encrypt_async_wait() drains pending completions and restores
encrypt_pending to 1, expecting the caller to issue the final
decrement. However, if tls_encrypt_async_wait() returns an error
(rc != -EINPROGRESS), the function returns early at the error
cleanup block without decrementing encrypt_pending.

Since the -EBUSY path never submitted the request to the crypto
engine, tls_encrypt_done() callback will not fire for this request,
and the synchronous cleanup path (atomic_dec at line 599) is also
skipped. This leaves encrypt_pending permanently elevated by 1.

Fix the leak by adding atomic_dec(&ctx->encrypt_pending) before
returning on the -EBUSY error path.

Cc: stable@vger.kernel.org
Fixes: a9b8b18364ff ("net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption")
Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
---
 net/tls/tls_sw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 964ebc268ee4..97cfe06b1529 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -591,6 +591,7 @@ static int tls_do_encryption(struct sock *sk,
 		 * below on error, just remove the record and return.
 		 */
 		if (rc != -EINPROGRESS) {
+			atomic_dec(&ctx->encrypt_pending);
 			list_del(&rec->list);
 			return rc;
 		}
-- 
2.50.1 (Apple Git-155)

Re: [PATCH] tls: fix encrypt_pending refcount leak on -EBUSY error path

[Sabrina Dubroca]

2026-06-12, 10:01:33 +0800, WenTao Liang wrote:
> In tls_do_encryption(), when crypto_aead_encrypt() returns -EBUSY,
> tls_encrypt_async_wait() drains pending completions and restores
> encrypt_pending to 1, expecting the caller to issue the final
> decrement. However, if tls_encrypt_async_wait() returns an error
> (rc != -EINPROGRESS), the function returns early at the error
> cleanup block without decrementing encrypt_pending.
> 
> Since the -EBUSY path never submitted the request to the crypto
> engine, tls_encrypt_done() callback will not fire for this request,
> and the synchronous cleanup path (atomic_dec at line 599) is also
> skipped. This leaves encrypt_pending permanently elevated by 1.

No. Please fix whatever scanner/LLM you're using to generate those.

-- 
Sabrina