Re: [PATCH v19 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] Unbounded wait_event() in spacc_check_modes() can hang the kernel unkillably on hardware failure
--

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

crypto: spacc - Add SPAcc AUTODETECT Support

This commit adds autodetect configuration support to the SPAcc driver.
It attempts to automatically detect the supported cryptographic algorithms
at runtime instead of relying on a static configuration.

> diff --git a/drivers/crypto/dwc-spacc/spacc_core.c b/drivers/crypto/dwc-spacc/spacc_core.c
> index b4eaab534c8ee..ec77a13612756 100644
> --- a/drivers/crypto/dwc-spacc/spacc_core.c
> +++ b/drivers/crypto/dwc-spacc/spacc_core.c
[ ... ]
> +	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]
Is it safe to use an unbounded wait here?

If the hardware is faulty or drops the interrupt, wait_event() will hang
indefinitely in TASK_UNINTERRUPTIBLE (D-state). If the driver is built-in,
this would hang the entire kernel boot process. If it is loaded as a module,
it permanently hangs the loading process.

While the comment explains this is a deliberate tradeoff to avoid a
use-after-free, could we use wait_event_timeout() instead? If the timeout
expires, the driver could fail the probe and intentionally leak the DMA
buffers and job context (or reset the hardware block) to safely prevent the
UAF without permanently hanging the system.

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

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