Re: [PATCH v18 3/4] crypto: spacc - Add SPAcc AUTODETECT Support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unkillable wait during hardware autodetection can permanently hang the kernel if the device drops unsupported jobs.
--

--- Patch [3]: [PATCH v18 3/4] crypto: spacc - Add SPAcc AUTODETECT Support ---
commit 9e2e636bd5aacb282e1058d2b08e95919016a954
Author: Pavitrakumar Managutte <pavitrakumarm@vayavyalabs.com>

crypto: spacc - Add SPAcc AUTODETECT Support

This commit adds hardware autodetect support to the SPAcc crypto driver.
It iterates through multiple cryptographic algorithms and submits test jobs
to determine if the hardware supports them.

> diff --git a/drivers/crypto/dwc-spacc/spacc_core.c b/drivers/crypto/dwc-spacc/spacc_core.c
> index 36ab428301867..b6ed04d936dba 100644
> --- a/drivers/crypto/dwc-spacc/spacc_core.c
> +++ b/drivers/crypto/dwc-spacc/spacc_core.c

[ ... ]

> +static int spacc_check_modes(struct spacc_device *spacc, int algo_mode,
> +			      int keysz_idx, void *virt, char *key,
> +			      struct pdu_ddt *ddt)
> +{

[ ... ]

> +	err = spacc_packet_enqueue_ddt(spacc, rc, ddt, ddt, proclen, 0,
> +				       aadlen, 0, 0, 0);
> +	job = &spacc->job[rc];
> +
> +	if (err == 0) {
> +		/*
> +		 * No timeout, not interruptible: this only returns once
> +		 * job_done is actually true, i.e. the hardware has
> +		 * genuinely relinquished the job. That guarantees it is
> +		 * always safe to close the job/context and (via the
> +		 * caller) free the DMA buffer immediately below --
> +		 * there is no "unconfirmed" case left to handle.
> +		 *
> +		 * Tradeoff: if the hardware ever genuinely fails to
> +		 * complete a submitted job, this hangs here
> +		 * unkillably (TASK_UNINTERRUPTIBLE, no timeout) for the
> +		 * rest of probe. Accepted deliberately in place of the
> +		 * abandoned-job/UAF risk of giving up early with no
> +		 * hardware cancel available.
> +		 */
> +		wait_event(job->waitq, job->job_done);

[Severity: High]
Could this wait_event call permanently hang the kernel during initialization?

If the hardware silently drops a command for an unsupported algorithm instead
of completing it with an explicit error status, no interrupt will be raised.

Since autodetection inherently tests invalid or unsupported states, using
wait_event without a timeout could cause the boot or driver probe path to hang
indefinitely in an uninterruptible state.

Could a timeout like wait_event_timeout be used here instead, and perhaps
handle the hardware failure gracefully (e.g. by resetting the hardware or
quarantining the test DMA buffer) rather than intentionally hanging the system?

> +
> +		job->job_done = 0;
> +		err = job->job_err;
> +	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723120156.285270-1-pavitrakumarm@vayavyalabs.com?part=3