Re: [PATCH v12 20/20] dmaengine: ti: k3-udma: Validate resource ID and fix logging in reservation

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dmaengine: ti: k3-udma: missing lock in resource reservation leads to TOCTOU
--

commit 710a674e34f14eb0ae15cca2c7bdeb8e8a4b36b1
Author: Sai Sree Kartheek Adivi <s-adivi@ti.com>

dmaengine: ti: k3-udma: Validate resource ID and fix logging in reservation

The __udma_reserve_##res macro currently lacks a bounds check for the
provided id. If a caller passes an ID exceeding the resource count,
test_bit() performs an out-of-bounds memory access on the bitmap.
This commit adds a bounds check and corrects the error codes and logging
for resource reservations.

> diff --git a/drivers/dma/ti/k3-udma-common.c b/drivers/dma/ti/k3-udma-common.c
> index 846c1d72eaba9..a22dcaca754b9 100644
> --- a/drivers/dma/ti/k3-udma-common.c
> +++ b/drivers/dma/ti/k3-udma-common.c
> @@ -2046,9 +2046,14 @@ struct udma_##res *__udma_reserve_##res(struct udma_dev *ud,	\
>  					       int id)			\
>  {									\
>  	if (id >= 0) {							\
> +		if (id >= ud->res##_cnt) {				\
> +			dev_err(ud->dev,				\
> +				#res " id %d is out of bounds.\n", id);	\
> +			return ERR_PTR(-EINVAL);			\
> +		}							\
>  		if (test_bit(id, ud->res##_map)) {			\
> -			dev_err(ud->dev, "res##%d is in use\n", id);	\
> -			return ERR_PTR(-ENOENT);			\
> +			dev_err(ud->dev, #res "%d is in use\n", id);	\
> +			return ERR_PTR(-EBUSY);			\
>  		}							\

[Severity: High]
Does this missing lock lead to a time-of-check to time-of-use race condition?

The macro __udma_reserve_##res() performs an availability check locklessly
using test_bit() here, or find_next_zero_bit() later in the macro:

    id = find_next_zero_bit(ud->res##_map, ud->res##_cnt,
                            start);

This is followed by an update completing an unsafe read-modify-write sequence:

    set_bit(id, ud->res##_map);

Similarly, __udma_alloc_gp_rflow_range() performs lockless discovery of the
free GP flow region:

    start = bitmap_find_next_zero_area(tmp,
                                       ud->rflow_cnt,
                                       tmp_from, cnt, 0);

And marks the GP flow region as allocated, completing a separate unsafe
read-modify-write sequence:

    bitmap_set(ud->rflow_gp_map_allocated, start, cnt);

Because exported glue-layer functions like k3_udma_glue_request_tx_chn()
call these helpers directly during client probe without holding any
driver-level lock (such as ud->lock), can concurrent probes race and
double-allocate hardware resources?

>  	} else {							\
>  		int start;						\

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007102936.2402427-1-s-adivi@ti.com?part=20