Re: [PATCH v9 00/14] crypto: qce - Fix crypto self-test failures

[Herbert Xu <herbert@gondor.apana.org.au>]

On Fri, Oct 02, 2026 at 10:31:41PM +0300, Bartosz Golaszewski wrote:
>
> > Please check the Sashiko comments:
> >
> > https://sashiko.dev/#/patchset/20260922-qce-fix-self-tests-v9-0-b1aa742e79af%40oss.qualcomm.com
> >
> 
> I've gone through them. None of the issues were introduced by this series, all
> are pre-existing. I've added them to my list and will fix them. Can we not
> delay this series any longer and instead work in smaller steps since the crypto
> algos will be disabled by default anyway?

The very first comment appears to be pointing to new code:

> > +/*
> > + * BAM DMA cannot handle zero-length transfers, so the driver always holds
> > + * back at least one byte to submit to the engine. A zero rctx->buflen at
> > + * finalization time does not necessarily mean the message is empty: the
> > + * caller may have imported a state that already reflects some hashed data
> > + * with nothing currently buffered. Handle both cases through the software
> > + * fallback: reconstruct the running state when there is one instead of
> > + * assuming the message is empty.
> > + */
> > +static int qce_ahash_finalize_zero(struct ahash_request *req)
> > +{
> > +	struct qce_sha_reqctx *rctx = ahash_request_ctx_dma(req);
> > +	HASH_FBREQ_ON_STACK(fbreq, req);
> > +	struct __sha256_ctx core;
> > +	struct scatterlist sg;
> > +	int ret;
> > +
> > +	sg_init_one(&sg, NULL, 0);
> Can this trigger a kernel panic during zero-length finalization?
> qce_ahash_finalize_zero() creates a dummy scatterlist by calling
> sg_init_one(&sg, NULL, 0).
> sg_init_one() unconditionally calls sg_set_buf(), which attempts to resolve
> the page via virt_to_page(NULL).
> If CONFIG_DEBUG_SG is enabled, this triggers a BUG_ON(!virt_addr_valid(buf))
> kernel panic, because 0 is not a valid linear map address.
> If disabled, it results in a bogus PFN being stored in the scatterlist,
> leading to potential invalid memory access during software fallback operations.
> This path appears reachable by untrusted userspace via AF_ALG performing a
> zero-length HMAC finalization.

How is this a pre-existing issue?

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