linux-kernel - Re: [v2 PATCH] crypto: seqiv - Do not use req->iv after crypto_aead

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CADvbK_e1b1uF9izfeV3KOuEOckCBXnFKL4NRjb3ZGHih7F89hA@mail.gmail.com>
Date: Fri, 19 Dec 2025 12:58:49 -0500
From: Xin Long <lucien.xin@...il.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org, 
	"David S . Miller" <davem@...emloft.net>, Steffen Klassert <steffen.klassert@...unet.com>
Subject: Re: [v2 PATCH] crypto: seqiv - Do not use req->iv after crypto_aead_encrypt

On Wed, Dec 17, 2025 at 1:15 AM Herbert Xu <herbert@...dor.apana.org.au> wrote:
>
> On Sun, Dec 14, 2025 at 04:42:29PM -0500, Xin Long wrote:
> > Xiumei reported a UAF crash when intel_qat is used in ipsec:
> >
> > [] BUG: KASAN: slab-use-after-free in seqiv_aead_encrypt+0x81a/0x8f0
> > [] Call Trace:
> > []  <TASK>
> > []  seqiv_aead_encrypt+0x81a/0x8f0
> > []  esp_output_tail+0x706/0x1be0 [esp4]
> > []  esp_output+0x4bb/0x9bb [esp4]
> > []  xfrm_output_one+0xbac/0x10d0
> > []  xfrm_output_resume+0x11e/0xc30
> > []  xfrm4_output+0x109/0x460
> > []  __ip_queue_xmit+0xc51/0x17f0
> > []  __tcp_transmit_skb+0x2555/0x3240
> > []  tcp_write_xmit+0x88f/0x3df0
> > []  __tcp_push_pending_frames+0x94/0x320
> > []  tcp_rcv_established+0x79f/0x3540
> > []  tcp_v4_do_rcv+0x4ae/0x8a0
> > []  __release_sock+0x29b/0x3b0
> > []  release_sock+0x53/0x1d0
> > []  tcp_sendmsg+0x35/0x40
> >
> > [] Allocated by task 7455:
> > []  esp_output_tail+0x151/0x1be0 [esp4]
> > []  esp_output+0x4bb/0x9bb [esp4]
> > []  xfrm_output_one+0xbac/0x10d0
> > []  xfrm_output_resume+0x11e/0xc30
> > []  xfrm4_output+0x109/0x460
> > []  __ip_queue_xmit+0xc51/0x17f0
> > []  __tcp_transmit_skb+0x2555/0x3240
> > []  tcp_write_xmit+0x88f/0x3df0
> > []  __tcp_push_pending_frames+0x94/0x320
> > []  tcp_rcv_established+0x79f/0x3540
> > []  tcp_v4_do_rcv+0x4ae/0x8a0
> > []  __release_sock+0x29b/0x3b0
> > []  release_sock+0x53/0x1d0
> > []  tcp_sendmsg+0x35/0x40
> >
> > [] Freed by task 0:
> > []  kfree+0x1d5/0x640
> > []  esp_output_done+0x43d/0x870 [esp4]
> > []  qat_alg_callback+0x83/0xc0 [intel_qat]
> > []  adf_ring_response_handler+0x377/0x7f0 [intel_qat]
> > []  adf_response_handler+0x66/0x170 [intel_qat]
> > []  tasklet_action_common+0x2c9/0x460
> > []  handle_softirqs+0x1fd/0x860
> > []  __irq_exit_rcu+0xfd/0x250
> > []  irq_exit_rcu+0xe/0x30
> > []  common_interrupt+0xbc/0xe0
> > []  asm_common_interrupt+0x26/0x40
> >
> > The req allocated in esp_output_tail() may complete asynchronously when
> > crypto_aead_encrypt() returns -EINPROGRESS or -EBUSY. In this case, the
> > req can be freed in qat_alg_callback() via esp_output_done(), yet
> > seqiv_aead_encrypt() still accesses req->iv after the encrypt call
> > returns:
> >
> >   if (unlikely(info != req->iv))
> >
> > There is no guarantee that req remains valid after an asynchronous
> > submission, and this access will result in this use-after-free.
> >
> > Fix this by checking req->iv only when the encryption completes
> > synchronously, and skipping the check for -EINPROGRESS/-EBUSY returns.
> >
> > Fixes: 856e3f4092cf ("crypto: seqiv - Add support for new AEAD interface")
> > Reported-by: Xiumei Mu <xmu@...hat.com>
> > Signed-off-by: Xin Long <lucien.xin@...il.com>
> > ---
> >  crypto/seqiv.c | 8 +++-----
> >  1 file changed, 3 insertions(+), 5 deletions(-)
>
> Thanks for catching this! I'd prefer not using req->iv at all
> though, something like:
>
> ---8<---
> As soon as crypto_aead_encrypt is called, the underlying request
> may be freed by an asynchronous completion.  Thus dereferencing
> req->iv after it returns is invalid.
>
> Instead of checking req->iv against info, create a new variable
> unaligned_info and use it for that purpose instead.
>
> Fixes: 0a270321dbf9 ("[CRYPTO] seqiv: Add Sequence Number IV Generator")
> Reported-by: Xiumei Mu <xmu@...hat.com>
> Reported-by: Xin Long <lucien.xin@...il.com>
> Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>
>
Hi, Herbert,

Which upstream git repo will this patch be applied to?

Thanks.