Re: [PATCH v22 07/14] crypto: qce - Cancel work on device detach

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The devres teardown order allows the workqueue to execute after the mutex is destroyed and DMA resources are freed, leading to Use-After-Destroy and Use-After-Free vulnerabilities.
--

--- Patch [7]: [PATCH v22 07/14] crypto: qce - Cancel work on device detach ---
commit 6d9da6ba83fc4e0d03cfd0b8d7734f1b49da2f07
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

crypto: qce - Cancel work on device detach

The commit moves the initialization of the workqueue earlier in the probe
sequence and adds a devres action to ensure it is cancelled on device detach
or probe error. It also ensures all DMA transfers are terminated synchronously
during the DMA release action.

Closes: https://sashiko.dev/#/patchset/20260427-qcom-qce-cmd-descr-v16-0-945fd1cafbbc%40oss.qualcomm.com?part=7

> diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
> index ac74f69914d61..b52a26ffff5ee 100644
> --- a/drivers/crypto/qce/core.c
> +++ b/drivers/crypto/qce/core.c
[ ... ]
> @@ -226,6 +233,11 @@ static int qce_crypto_probe(struct platform_device *pdev)
>  	if (ret)
>  		return ret;
>  
> +	INIT_WORK(&qce->done_work, qce_req_done_work);
> +	ret = devm_add_action_or_reset(dev, qce_cancel_work, &qce->done_work);
> +	if (ret)
> +		return ret;
> +

[Severity: High]
This isn't a bug introduced by this patch, but does this devres registration
order leave a window for use-after-free and use-after-destroy during teardown?

Devres actions execute in LIFO order based on registration. Because
qce_cancel_work() is registered here before devm_qce_dma_request() and
devm_mutex_init() are called later in the probe function, the teardown
process will execute in this order:

1. devm_mutex_init teardown (mutex is destroyed)
2. devm_qce_dma_request teardown (DMA channels and buffers are freed)
3. qce_cancel_work() executes

If qce_req_done_work() is scheduled and runs after the mutex is destroyed or
the DMA resources are freed, but before qce_cancel_work() completes, could it
access the destroyed mutex or freed DMA resources?

>  	ret = devm_qce_dma_request(qce->dev, &qce->dma);
>  	if (ret)
>  		return ret;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-qcom-qce-cmd-descr-v22-0-ff0d18b27246@oss.qualcomm.com?part=7