Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: yuri08 <nvt031@gmail.com>
Cc: davem@davemloft.net, w@1wt.eu, linux-crypto@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] crypto: algif_aead - Prevent async UAF on early socket close
Date: Mon, 11 May 2026 13:32:24 +0800	[thread overview]
Message-ID: <agFp6PwyWsnvr5Gk@gondor.apana.org.au> (raw)
In-Reply-To: <CAFpG_BHU49CKUpak795wkiczROiKUX8CsN2dp_94s4P5M9rr4Q@mail.gmail.com>

On Sun, May 10, 2026 at 09:05:57PM +0700, yuri08 wrote:
> When an AEAD request falls back to the asynchronous software path (e.g.,
> cryptd), the Crypto API returns -EINPROGRESS and control returns to
> user-space. If user-space immediately closes the socket fd, the memory
> mapping for the RX SGL (req->dst) provided via recvmsg is torn down
> while the cryptd workqueue is still actively writing to it (e.g., during
> authenc_esn_decrypt ESN scratch writes).
> 
> To mitigate this race condition without adding complex pinning mechanisms,
> we utilize the crypto backlog capability. By adding
> CRYPTO_TFM_REQ_MAY_BACKLOG to the async callback flags, we ensure that
> the crypto core properly serializes the request completion, preventing
> the socket resources from being released by af_alg_release() while the
> workqueue is still processing the destination buffers.
> 
> Fixes: a664bf3d603d ("crypto: algif_aead - Revert to operating
> out-of-place")
> Signed-off-by: NGUYEN TUAN <nvt031@gmail.com>
> ---
>  crypto/algif_aead.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
> index cb651ab58d62..123456789abcd 100644
> --- a/crypto/algif_aead.c
> +++ b/crypto/algif_aead.c
> @@ -229,7 +229,8 @@ static int _aead_recvmsg(struct socket *sock, struct
> msghdr *msg,
>          areq->outlen = outlen;
> 
>          aead_request_set_callback(&areq->cra_u.aead_req,
> -  CRYPTO_TFM_REQ_MAY_SLEEP,
> +  CRYPTO_TFM_REQ_MAY_SLEEP |
> +  CRYPTO_TFM_REQ_MAY_BACKLOG,

This patch makes no sense.  We got rid of MAY_BACKLOG back in 2020
specifically because it causes the kind of problems that you're
reporting.

On a modern kernel, the socket reference is meant to keep the socket
from releasing its data prematurely.  The socket reference is only
dropped after completion.

Is it possible that you're using some ancient kernel dating from
the 2010's? Because from the context of the patch that you sent
in private, it appears to indicate that MAY_BACKLOG was still
being used.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

           reply	other threads:[~2026-05-11  5:32 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <CAFpG_BHU49CKUpak795wkiczROiKUX8CsN2dp_94s4P5M9rr4Q@mail.gmail.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=agFp6PwyWsnvr5Gk@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=davem@davemloft.net \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nvt031@gmail.com \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox