Re: [PATCH crypto 2/2] crypto: safexcel - Map AEAD buffers with accurate DMA directions

[Ralf Lici <ralf@mandelbit.com>]

On Thu, 08 Oct 2026 18:53:18 +1100, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Mon, Sep 28, 2026 at 12:25:00PM +0200, Ralf Lici wrote:
> >
> > For an out-of-place request, the caller may have already populated the
> > reserved destination AAD area. The AEAD API says that this area will not
> > be written by the cipher operation:
>
> That's what I was asking.  Which caller is doing this and thus
> would be broken without your patch?
>

The caller which exposed this is the ovpn UDP-GSO transmit path [1],
part of a series currently under review and not in mainline yet. It
builds an out-of-place AEAD request and explicitly copies the
authenticated header into the reserved destination prefix before
submitting it:

  ovpn_aead_encrypt_header(..., aad);
  skb_store_bits(gso_skb, offset, aad, aad_size);

The source AAD then points to the temporary aad buffer, while the
destination AAD points into gso_skb (they are separate storage). The
accelerator skips the destination prefix as required by the AEAD API,
but safexcel maps it as DMA_FROM_DEVICE, so SWIOTLB may copy untouched
bounce-buffer contents over the header during unmap. This is the
out-of-place case in which I reproduced the corruption.

Technically, the in-tree ESP out-of-place path also constructs its
destination around an already initialized header, but my ESP tests did
not reproduce the corruption, so ovpn is the concrete demonstrated case
here.

[1] https://lore.kernel.org/openvpn-devel/f075b9782b14d64756c84e132c138482f08287b9.1790843153.git.ralf@mandelbit.com/

-- 
Ralf Lici
Mandelbit Srl