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

[Bartosz Golaszewski]

On Thu, 8 Oct 2026 10:35:21 +0200, Herbert Xu
<herbert at gondor.apana.org.au> said:
> 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?
>

Sorry, this and a couple others were introduced here, v10 coming up.

Bart