Re: [PATCH 4/4] crypto: iaa - use bounce buffer for multi-sg decompress input

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Software fallback decompression writes directly to `req->dst` from the CPU while it is still mapped for DMA (`DMA_FROM_DEVICE`), causing silent data corruption if SWIOTLB (bounce buffers) is active.
--

--- Patch [4]: [PATCH 4/4] crypto: iaa - use bounce buffer for multi-sg decompress input ---
commit b4edd2dc0b34db120356af61156eef630f99393a
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>

crypto: iaa - use bounce buffer for multi-sg decompress input

This patch introduces a pre-allocated bounce page to linearize small 
multi-entry source scatterlists for the IAA hardware. This allows the 
driver to decompress these requests in hardware instead of falling back 
to software decompression.

> diff --git a/drivers/crypto/intel/iaa/iaa_crypto_main.c b/drivers/crypto/intel/iaa/iaa_crypto_main.c
> index 8f68b1478476e..54bde11c454c9 100644
> --- a/drivers/crypto/intel/iaa/iaa_crypto_main.c
> +++ b/drivers/crypto/intel/iaa/iaa_crypto_main.c

[ ... ]

> @@ -1124,7 +1147,7 @@ static void iaa_desc_complete(struct idxd_desc *idxd_desc,
>  	}
>  err:
>  	dma_unmap_sg(dev, ctx->req->dst, sg_nents(ctx->req->dst), DMA_FROM_DEVICE);
> -	dma_unmap_sg(dev, ctx->req->src, sg_nents(ctx->req->src), DMA_TO_DEVICE);
> +	iaa_unmap_src(dev, ctx->req);

[Severity: Critical]
This is a pre-existing issue, but does the software fallback mechanism in
iaa_desc_complete() risk silent data corruption if SWIOTLB bounce buffers
are active?

When a decompression request fails in hardware (for example, with an
IAA_ANALYTICS_ERROR), the completion handler falls back to software by
calling deflate_generic_decompress(). This software fallback correctly 
writes the decompressed data into the req->dst scatterlist using the CPU.

However, req->dst is still actively mapped for DMA_FROM_DEVICE. When the
code progresses to this error path and calls dma_unmap_sg() with
DMA_FROM_DEVICE, will SWIOTLB physically copy the contents of the device
bounce buffer (which holds the failed hardware output) over the CPU buffer? 

If so, this would overwrite the successfully decompressed data, which could 
lead to memory corruption if used with subsystems like zswap. Does req->dst 
need to be unmapped prior to invoking deflate_generic_decompress()?

>  out:
>  	if (ret != 0)
>  		dev_dbg(dev, "asynchronous compress failed ret=%d\n", ret);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713-iaa-crypto-fixes-zswap-v1-0-65cac23c684d@intel.com?part=4