[PATCH RESEND v5] dmaengine: sun6i-dma: Fix use-after-free in error handling paths

[PATCH RESEND v5] dmaengine: sun6i-dma: Fix use-after-free in error handling paths

[Hongling Zeng]

In error handling paths, the for loop frees v_lli in the loop body,
then accesses v_lli->v_lli_next and v_lli->p_lli_next in the
increment expression, which is use-after-free.

Fix by refactoring the cleanup into a helper function sun6i_dma_free_desc()
that saves both the next virtual and physical pointers before freeing the
current node, preventing the use-after-free.

Fixes: 555859308723 ("dmaengine: Add driver for Allwinner sun6i DMA")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Suggested-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

---
Changes in v2:
 -Refactored the fix to avoid code duplication by creating a helper function
  sun6i_dma_free_lli_list() that handles LLI list cleanup
 -Add Suggested-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
Change in v3:
 -Further refactoring to move txd handling into the helper function
  as suggested by Jernej
---
Change in v4:
 -Add reviewed-by
---
Change in v5:
 -Correct the commit message.
---
 drivers/dma/sun6i-dma.c | 31 ++++++++++++++++---------------
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index fcc88a74d821..e161fc298b86 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -406,16 +406,12 @@ static inline void sun6i_dma_dump_lli(struct sun6i_vchan *vchan,
 		v_lli->len, v_lli->para, v_lli->p_lli_next);
 }
 
-static void sun6i_dma_free_desc(struct virt_dma_desc *vd)
+static void sun6i_dma_free_desc(struct sun6i_dma_dev *sdev,
+				struct sun6i_desc *txd)
 {
-	struct sun6i_desc *txd = to_sun6i_desc(&vd->tx);
-	struct sun6i_dma_dev *sdev = to_sun6i_dma_dev(vd->tx.chan->device);
 	struct sun6i_dma_lli *v_lli, *v_next;
 	dma_addr_t p_lli, p_next;
 
-	if (unlikely(!txd))
-		return;
-
 	p_lli = txd->p_lli;
 	v_lli = txd->v_lli;
 
@@ -432,6 +428,17 @@ static void sun6i_dma_free_desc(struct virt_dma_desc *vd)
 	kfree(txd);
 }
 
+static void sun6i_dma_free_desc_virt(struct virt_dma_desc *vd)
+{
+	struct sun6i_desc *txd = to_sun6i_desc(&vd->tx);
+	struct sun6i_dma_dev *sdev = to_sun6i_dma_dev(vd->tx.chan->device);
+
+	if (unlikely(!txd))
+		return;
+
+	sun6i_dma_free_desc(sdev, txd);
+}
+
 static int sun6i_dma_start_desc(struct sun6i_vchan *vchan)
 {
 	struct sun6i_dma_dev *sdev = to_sun6i_dma_dev(vchan->vc.chan.device);
@@ -788,10 +795,7 @@ static struct dma_async_tx_descriptor *sun6i_dma_prep_slave_sg(
 	return vchan_tx_prep(&vchan->vc, &txd->vd, flags);
 
 err_lli_free:
-	for (p_lli = txd->p_lli, v_lli = txd->v_lli; v_lli;
-	     p_lli = v_lli->p_lli_next, v_lli = v_lli->v_lli_next)
-		dma_pool_free(sdev->pool, v_lli, p_lli);
-	kfree(txd);
+	sun6i_dma_free_desc(sdev, txd);
 	return NULL;
 }
 
@@ -869,10 +873,7 @@ static struct dma_async_tx_descriptor *sun6i_dma_prep_dma_cyclic(
 	return vchan_tx_prep(&vchan->vc, &txd->vd, flags);
 
 err_lli_free:
-	for (p_lli = txd->p_lli, v_lli = txd->v_lli; v_lli;
-	     p_lli = v_lli->p_lli_next, v_lli = v_lli->v_lli_next)
-		dma_pool_free(sdev->pool, v_lli, p_lli);
-	kfree(txd);
+	sun6i_dma_free_desc(sdev, txd);
 	return NULL;
 }
 
@@ -1432,7 +1433,7 @@ static int sun6i_dma_probe(struct platform_device *pdev)
 		struct sun6i_vchan *vchan = &sdc->vchans[i];
 
 		INIT_LIST_HEAD(&vchan->node);
-		vchan->vc.desc_free = sun6i_dma_free_desc;
+		vchan->vc.desc_free = sun6i_dma_free_desc_virt;
 		vchan_init(&vchan->vc, &sdc->slave);
 	}
 
-- 
2.25.1

Re: [PATCH RESEND v5] dmaengine: sun6i-dma: Fix use-after-free in error handling paths

[sashiko-bot]

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

Pre-existing issues:
- [High] Missing input validation in `sun6i_dma_prep_dma_cyclic()` leads to a divide-by-zero panic or a NULL pointer dereference when setting up the cyclic list.
- [High] Failing to validate `sg_len > 0` in `sun6i_dma_prep_slave_sg()` allows submission of an empty descriptor, leading to a hardware fault.
- [High] A race condition in `sun6i_dma_tx_status()` leads to a Use-After-Free when querying the status of a transfer.
--

--- Patch [1]: [PATCH RESEND v5] dmaengine: sun6i-dma: Fix use-after-free in error handling  paths ---
commit f42009e17697997cd6fc8eda0aef5712caa48d76
Author: Hongling Zeng <zenghongling@kylinos.cn>
Subject: dmaengine: sun6i-dma: Fix use-after-free in error handling paths

This commit fixes a use-after-free in the error handling paths of the
sun6i-dma driver by refactoring the descriptor cleanup into a new helper
function. It also introduces a virtual descriptor freeing helper for vchan.

> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index a9a254dbf8cb9..7a79f346250a5 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c

[ ... ]

> @@ -788,10 +795,7 @@ static struct dma_async_tx_descriptor *sun6i_dma_prep_slave_sg(
>  	return vchan_tx_prep(&vchan->vc, &txd->vd, flags);
>  
>  err_lli_free:

[Severity: High]
This isn't a bug introduced by this patch, but does the validation in
sun6i_dma_prep_slave_sg() need to check for empty scatterlists?

The function checks if the scatterlist pointer is valid:

if (!sgl)
    return NULL;

However, if sg_len is 0, the for_each_sg() loop is bypassed entirely.
This leaves txd->p_lli as 0.  When this descriptor is later executed by
sun6i_dma_start_desc(), the hardware LLI address register is programmed
with physical address 0:

writel(pchan->desc->p_lli, pchan->base + DMA_CHAN_LLI_ADDR);

Could this cause a hardware fault by instructing the DMA controller to
fetch its configuration from physical address 0?

> -	for (p_lli = txd->p_lli, v_lli = txd->v_lli; v_lli;
> -	     p_lli = v_lli->p_lli_next, v_lli = v_lli->v_lli_next)
> -		dma_pool_free(sdev->pool, v_lli, p_lli);
> -	kfree(txd);
> +	sun6i_dma_free_desc(sdev, txd);
>  	return NULL;
>  }

[ ... ]

> @@ -869,10 +873,7 @@ static struct dma_async_tx_descriptor *sun6i_dma_prep_dma_cyclic(
>  	return vchan_tx_prep(&vchan->vc, &txd->vd, flags);
>  
>  err_lli_free:

[Severity: High]
This is a pre-existing issue, but I noticed a potential divide-by-zero
and NULL pointer dereference in sun6i_dma_prep_dma_cyclic().

If a caller passes period_len as 0, does this calculation cause a
divide-by-zero exception?

unsigned int i, periods = buf_len / period_len;

Additionally, if buf_len is less than period_len, periods evaluates to 0.
This skips the allocation loop entirely, leaving the prev pointer
uninitialized (NULL).  Would the subsequent attempt to make the list
cyclic cause a NULL pointer dereference?

prev->p_lli_next = txd->p_lli;

> -	for (p_lli = txd->p_lli, v_lli = txd->v_lli; v_lli;
> -	     p_lli = v_lli->p_lli_next, v_lli = v_lli->v_lli_next)
> -		dma_pool_free(sdev->pool, v_lli, p_lli);
> -	kfree(txd);
> +	sun6i_dma_free_desc(sdev, txd);
>  	return NULL;
>  }

[ ... ]

[Severity: High]
This is a pre-existing issue, but I noticed a potential race condition
when querying the status of a transfer.

In sun6i_dma_tx_status(), the function queries dma_cookie_status()
outside the channel lock:

ret = dma_cookie_status(chan, cookie, state);

If the cookie status is DMA_IN_PROGRESS, can the thread be preempted
before taking the lock?

During this window, the hardware interrupt could fire, completing the
transfer and triggering the vchan_complete tasklet which frees the
descriptor memory.

When sun6i_dma_tx_status() resumes and acquires the lock, it might fail
to find the descriptor in the pending lists and fall back to calculating
the size using the active physical channel state:

bytes = sun6i_get_chan_size(pchan);

Inside sun6i_get_chan_size(), this would dereference the freed descriptor:

pos = pchan->desc->p_lli;

Since pchan->desc is cleared by sun6i_dma_tasklet running sequentially
afterwards, could this lead to a use-after-free?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727061142.44195-1-zenghongling@kylinos.cn?part=1