[PATCH] dmaengine: fsl_raid: free resources in probe

[PATCH] dmaengine: fsl_raid: free resources in probe

[Rosen Penev]

Add free_irq() in the error unwind of fsl_re_chan_probe() and in
fsl_re_remove_chan() so the interrupt is always released.

Also add tasklet_kill(). Present in _remove but not _probe.

Also add platform_device_put on failure as of_platform_device_create()
increases the reference count and needs platform_device_put on failure.
Requires placing the pointer in the struct for the _remove function.
While at it, use platform_get/set_drvdata as there's no need for using a
device pointer for that.

Fixes: ad80da658bbc ("dmaengine: Driver support for FSL RaidEngine device.")
Assisted-by: opencode:hy3-free
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 drivers/dma/fsl_raid.c | 32 ++++++++++++++++++++------------
 drivers/dma/fsl_raid.h |  1 +
 2 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/dma/fsl_raid.c b/drivers/dma/fsl_raid.c
index 0b0b4e8fc821..b1a10292324d 100644
--- a/drivers/dma/fsl_raid.c
+++ b/drivers/dma/fsl_raid.c
@@ -212,10 +212,11 @@ static void fsl_re_dequeue(struct tasklet_struct *t)
 /* Per Job Ring interrupt handler */
 static irqreturn_t fsl_re_isr(int irq, void *data)
 {
+	struct platform_device *pdata = data;
 	struct fsl_re_chan *re_chan;
 	u32 irqstate, status;
 
-	re_chan = dev_get_drvdata((struct device *)data);
+	re_chan = platform_get_drvdata(pdata);
 
 	irqstate = in_be32(&re_chan->jrregs->jr_interrupt_status);
 	if (!irqstate)
@@ -645,7 +646,7 @@ static int fsl_re_chan_probe(struct platform_device *ofdev,
 	struct platform_device *chan_ofdev;
 
 	dev = &ofdev->dev;
-	re_priv = dev_get_drvdata(dev);
+	re_priv = platform_get_drvdata(ofdev);
 	dma_dev = &re_priv->dma_dev;
 
 	chan = devm_kzalloc(dev, sizeof(*chan), GFP_KERNEL);
@@ -656,8 +657,7 @@ static int fsl_re_chan_probe(struct platform_device *ofdev,
 	chan_ofdev = of_platform_device_create(np, NULL, dev);
 	if (!chan_ofdev) {
 		dev_err(dev, "Not able to create ofdev for jr %d\n", q);
-		ret = -EINVAL;
-		goto err_free;
+		return -EINVAL;
 	}
 
 	/* read reg property from dts */
@@ -683,17 +683,18 @@ static int fsl_re_chan_probe(struct platform_device *ofdev,
 	chandev = &chan_ofdev->dev;
 	tasklet_setup(&chan->irqtask, fsl_re_dequeue);
 
-	ret = request_irq(chan->irq, fsl_re_isr, 0, chan->name, chandev);
+	ret = request_irq(chan->irq, fsl_re_isr, 0, chan->name, chan_ofdev);
 	if (ret) {
 		dev_err(dev, "Unable to register interrupt for JR %d\n", q);
 		ret = -EINVAL;
-		goto err_free;
+		goto err_free_tasklet;
 	}
 
 	re_priv->re_jrs[q] = chan;
 	chan->chan.device = dma_dev;
 	chan->chan.private = chan;
 	chan->dev = chandev;
+	chan->ofdev = chan_ofdev;
 	chan->re_dev = re_priv;
 
 	spin_lock_init(&chan->desc_lock);
@@ -707,7 +708,7 @@ static int fsl_re_chan_probe(struct platform_device *ofdev,
 	if (!chan->inb_ring_virt_addr) {
 		dev_err(dev, "No dma memory for inb_ring_virt_addr\n");
 		ret = -ENOMEM;
-		goto err_free;
+		goto err_free_irq;
 	}
 
 	chan->oub_ring_virt_addr = dma_pool_alloc(chan->re_dev->hw_desc_pool,
@@ -739,7 +740,7 @@ static int fsl_re_chan_probe(struct platform_device *ofdev,
 	out_be32(&chan->jrregs->jr_config_1,
 		 FSL_RE_CFG1_CBSI | FSL_RE_CFG1_CBS0 | status);
 
-	dev_set_drvdata(chandev, chan);
+	platform_set_drvdata(chan_ofdev, chan);
 
 	/* Enable RE/CHAN */
 	out_be32(&chan->jrregs->jr_command, FSL_RE_ENABLE);
@@ -749,7 +750,12 @@ static int fsl_re_chan_probe(struct platform_device *ofdev,
 err_free_1:
 	dma_pool_free(chan->re_dev->hw_desc_pool, chan->inb_ring_virt_addr,
 		      chan->inb_phys_addr);
+err_free_irq:
+	free_irq(chan->irq, chan_ofdev);
+err_free_tasklet:
+	tasklet_kill(&chan->irqtask);
 err_free:
+	platform_device_put(chan_ofdev);
 	return ret;
 }
 
@@ -828,7 +834,7 @@ static int fsl_re_probe(struct platform_device *ofdev)
 		return -ENOMEM;
 	}
 
-	dev_set_drvdata(dev, re_priv);
+	platform_set_drvdata(ofdev, re_priv);
 
 	/* Parse Device tree to find out the total number of JQs present */
 	for_each_compatible_node_scoped(np, NULL, "fsl,raideng-v1.0-job-queue") {
@@ -864,21 +870,23 @@ static void fsl_re_remove_chan(struct fsl_re_chan *chan)
 {
 	tasklet_kill(&chan->irqtask);
 
+	free_irq(chan->irq, chan->ofdev);
+
 	dma_pool_free(chan->re_dev->hw_desc_pool, chan->inb_ring_virt_addr,
 		      chan->inb_phys_addr);
 
 	dma_pool_free(chan->re_dev->hw_desc_pool, chan->oub_ring_virt_addr,
 		      chan->oub_phys_addr);
+
+	platform_device_put(chan->ofdev);
 }
 
 static void fsl_re_remove(struct platform_device *ofdev)
 {
 	struct fsl_re_drv_private *re_priv;
-	struct device *dev;
 	int i;
 
-	dev = &ofdev->dev;
-	re_priv = dev_get_drvdata(dev);
+	re_priv = platform_get_drvdata(ofdev);
 
 	/* Cleanup chan related memory areas */
 	for (i = 0; i < re_priv->total_chans; i++)
diff --git a/drivers/dma/fsl_raid.h b/drivers/dma/fsl_raid.h
index adbfede330a7..34d362803610 100644
--- a/drivers/dma/fsl_raid.h
+++ b/drivers/dma/fsl_raid.h
@@ -270,6 +270,7 @@ struct fsl_re_chan {
 	struct list_head active_q; /* already issued on hw, not completed */
 	struct list_head submit_q;
 	struct list_head free_q; /* alloc available queue */
+	struct platform_device *ofdev;
 	struct device *dev;
 	struct fsl_re_drv_private *re_dev;
 	struct dma_chan chan;
-- 
2.55.0

Re: [PATCH] dmaengine: fsl_raid: free resources in probe

[sashiko-bot]

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

New issues:
- [High] Improper Device Cleanup / List Corruption
- [High] Race Condition / Teardown Order resulting in Use-After-Free
- [High] Double-Free / NULL Pointer Dereference due to Ignored Probe Error

Pre-existing issues:
- [High] Race Condition / Uninitialized Data in ISR
- [High] Resource Leak and Kernel Panic on JQ Node Parse Failure
- [High] Concurrency / Use-After-Free during DMA Unregistration
- [High] Buffer Overflow / Out-of-Bounds Write from Device Tree
--

--- Patch [1]: [PATCH] dmaengine: fsl_raid: free resources in probe ---
commit 6b03aff77ef1f481579072d2caa275fbf35f0665
Author: Rosen Penev <rosenp@gmail.com>

dmaengine: fsl_raid: free resources in probe

This patch adds resource cleanup in the error unwind path of
fsl_re_chan_probe and in fsl_re_remove_chan. It adds free_irq, tasklet_kill,
and platform_device_put, while switching to platform_get/set_drvdata.

> diff --git a/drivers/dma/fsl_raid.c b/drivers/dma/fsl_raid.c
> index 99945845d8b5e..5f9c92c86593e 100644
> --- a/drivers/dma/fsl_raid.c
> +++ b/drivers/dma/fsl_raid.c

[ ... ]

> @@ -672,17 +672,18 @@ static int fsl_re_chan_probe(struct platform_device *ofdev,
>  	chandev = &chan_ofdev->dev;
>  	tasklet_setup(&chan->irqtask, fsl_re_dequeue);
>  
> -	ret = request_irq(chan->irq, fsl_re_isr, 0, chan->name, chandev);
> +	ret = request_irq(chan->irq, fsl_re_isr, 0, chan->name, chan_ofdev);

[Severity: High]
This isn't a bug introduced by this patch, but by requesting the IRQ here, is
there a window where the interrupt can fire before platform_set_drvdata() is
called later in this function?

If the ISR runs immediately, it will read a NULL pointer from
platform_get_drvdata() and dereference it when reading the interrupt status.

>  	if (ret) {
>  		dev_err(dev, "Unable to register interrupt for JR %d\n", q);
>  		ret = -EINVAL;
> -		goto err_free;
> +		goto err_free_tasklet;
>  	}

[ ... ]

> @@ -738,7 +739,12 @@ static int fsl_re_chan_probe(struct platform_device *ofdev,
>  err_free_1:
>  	dma_pool_free(chan->re_dev->hw_desc_pool, chan->inb_ring_virt_addr,
>  		      chan->inb_phys_addr);
> +err_free_irq:
> +	free_irq(chan->irq, chan_ofdev);
> +err_free_tasklet:
> +	tasklet_kill(&chan->irqtask);
>  err_free:
> +	platform_device_put(chan_ofdev);

[Severity: High]
Does platform_device_put() correctly clean up the device created by
of_platform_device_create()?

Since of_platform_device_create() allocates and registers the device with
the system bus, the initial reference belongs to the device core. Does calling
platform_device_put() here drop a reference the driver doesn't own, leading
to a reference count underflow and a subsequent use-after-free?

Would of_platform_device_destroy() or platform_device_unregister() be the
correct teardown function to use instead?

[Severity: High]
If fsl_re_chan_probe() fails and executes these new destructors, does the
driver handle the failure correctly in fsl_re_probe()?

Looking at fsl_re_probe(), the return value of fsl_re_chan_probe() is ignored
and total_chans is incremented anyway:

fsl_re_probe() {
    ...
    for_each_child_of_node(np, child) {
        ...
        if (rc) {
            fsl_re_chan_probe(ofdev, child, ridx++, off);
            re_priv->total_chans++;
        }
    }
}

Since total_chans is still incremented, fsl_re_remove() will eventually
iterate over this failed channel and call fsl_re_remove_chan(). Does this
result in a double free of the IRQ and device, or a NULL pointer dereference
since the cleanup already happened in the probe error path?

>  	return ret;
>  }

[ ... ]

> @@ -819,7 +825,7 @@ static int fsl_re_probe(struct platform_device *ofdev)
>  		return -ENOMEM;
>  	}
>  
> -	dev_set_drvdata(dev, re_priv);
> +	platform_set_drvdata(ofdev, re_priv);

[Severity: High]
This isn't a bug introduced by this patch, but looking at fsl_re_probe(), is
there a risk of an out-of-bounds write if the device tree has too many child
nodes?

fsl_re_probe() {
    ...
    for_each_child_of_node(np, child) {
        ...
            fsl_re_chan_probe(ofdev, child, ridx++, off);
    }
}

fsl_re_chan_probe() uses this index to store the channel in re_jrs:
    re_priv->re_jrs[q] = chan;

Since re_jrs has a fixed size of 4, will this corrupt memory if more than 4 
job rings are defined in the device tree?

[Severity: High]
This is another pre-existing issue, but does fsl_re_probe() leak resources if
a secondary Job Queue node fails to parse?

fsl_re_probe() {
    ...
    for_each_compatible_node_scoped(np, NULL, "fsl,raideng-v1.0-job-queue") {
        rc = of_property_read_u32(np, "reg", &off);
        if (rc) {
            dev_err(dev, "Reg property not found in JQ node\n");
            return -ENODEV;
        }
        ...
}

If this early return is hit on a subsequent loop iteration, are the channels
probed in previous iterations leaked because fsl_re_remove() won't be called?

Could this also cause a kernel panic if an active IRQ fires and attempts to
access the unmapped re_regs since devres will clean up the mapped memory?

>  
>  	/* Parse Device tree to find out the total number of JQs present */
>  	for_each_compatible_node_scoped(np, NULL, "fsl,raideng-v1.0-job-queue") {

[ ... ]

> @@ -848,21 +854,23 @@ static void fsl_re_remove_chan(struct fsl_re_chan *chan)
>  {
>  	tasklet_kill(&chan->irqtask);
>  
> +	free_irq(chan->irq, chan->ofdev);

[Severity: High]
Is there a race condition here by calling free_irq() after tasklet_kill()?

If a hardware interrupt fires between tasklet_kill() and free_irq(), the ISR
will execute and re-schedule the tasklet. Will this result in a pending
tasklet running after the channel memory has been freed, causing a
use-after-free?

Should free_irq() be called first to ensure no new tasklets can be scheduled?

> +
>  	dma_pool_free(chan->re_dev->hw_desc_pool, chan->inb_ring_virt_addr,
>  		      chan->inb_phys_addr);
>  
>  	dma_pool_free(chan->re_dev->hw_desc_pool, chan->oub_ring_virt_addr,
>  		      chan->oub_phys_addr);
> +
> +	platform_device_put(chan->ofdev);

[Severity: High]
Similar to the probe error path, does platform_device_put() cause a reference
count underflow here?

Since the device was created with of_platform_device_create(), would
of_platform_device_destroy() or platform_device_unregister() be the correct
way to clean it up?

>  }
>  
>  static void fsl_re_remove(struct platform_device *ofdev)
>  {
>  	struct fsl_re_drv_private *re_priv;
> -	struct device *dev;
>  	int i;
>  
> -	dev = &ofdev->dev;
> -	re_priv = dev_get_drvdata(dev);
> +	re_priv = platform_get_drvdata(ofdev);
>  
>  	/* Cleanup chan related memory areas */
>  	for (i = 0; i < re_priv->total_chans; i++)

[Severity: High]
This is a pre-existing issue, but does fsl_re_remove() tear down the
channels in the wrong order relative to unregistering the DMA device?

fsl_re_remove() {
    ...
    for (i = 0; i < re_priv->total_chans; i++)
        fsl_re_remove_chan(re_priv->re_jrs[i]);

    dma_async_device_unregister(&re_priv->dma_dev);
}

Since dma_async_device_unregister() is called after destroying the channels,
is there a window where the DMA engine core might still issue new requests or
query channel status after the DMA pools and IRQs have been freed?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260718231716.230144-1-rosenp@gmail.com?part=1