Re: [PATCH v22 09/14] crypto: qce - Remove unused ignore_buf

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Background workqueue is cancelled after DMA channels and memory are freed, leading to a UAF if the work executes concurrently during device teardown.
- [High] Self-deadlock in `qce_handle_queue` when completing a backlog request.
--

--- Patch [9]: [PATCH v22 09/14] crypto: qce - Remove unused ignore_buf ---
commit 2247b3c61623eab5bba053110822c8e653d692e5
Author: Bartosz Golaszewski <brgl@kernel.org>

crypto: qce - Remove unused ignore_buf

This commit removes the unused ignore_buf field from the qce_dma_data struct.
It also moves the QCE_IGNORE_BUF_SZ definition to dma.c since it is only
used locally.

> diff --git a/drivers/crypto/qce/dma.c b/drivers/crypto/qce/dma.c
> index 7ec9d72fd690f..d1daa229361aa 100644
> --- a/drivers/crypto/qce/dma.c
> +++ b/drivers/crypto/qce/dma.c
[ ... ]
> @@ -43,8 +45,6 @@ int devm_qce_dma_request(struct device *dev, struct qce_dma_data *dma)
>  		goto error_nomem;
>  	}
>  
> -	dma->ignore_buf = dma->result_buf + QCE_RESULT_BUF_SZ;
> -
>  	return devm_add_action_or_reset(dev, qce_dma_release, dma);

[Severity: High]
This is a pre-existing issue, but does device teardown have a race condition
leading to a use-after-free here?

During device unbind, devres executes cleanup actions in reverse order.
In drivers/crypto/qce/core.c:qce_crypto_probe(), the devm action to cancel
the work queue is registered before devm_qce_dma_request() is called:

    ret = devm_add_action_or_reset(dev, qce_cancel_work, &qce->done_work);

This means qce_cancel_work() will run after qce_dma_release().

If a dma transfer just completed and scheduled qce->done_work,
qce_dma_release() will terminate pending dma transfers and free dma->result_buf
before the worker thread is actually canceled.

Could the worker thread then execute qce_req_done_work() and attempt to submit
a new dma transfer using the freed dma->result_buf and dma channels?


[Severity: High]
This is another pre-existing issue, but is there a risk of a self-deadlock in
qce_handle_queue() when completing a backlog request?

In drivers/crypto/qce/core.c:qce_handle_queue():

    if (backlog) {
        scoped_guard(mutex, &qce->lock)
            crypto_request_complete(backlog, -EINPROGRESS);
    }

The crypto_request_complete() callback is invoked while holding qce->lock.

If the submitter's completion callback immediately submits another request
(which is standard behavior for dm-crypt or ipsec when waiting for queue
space), it calls qce_async_request_enqueue().

This would re-enter qce_handle_queue() and attempt to acquire the same
non-recursive qce->lock again.

Can this cause a kernel thread self-deadlock when the queue is full?

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