Re: [PATCHv4] dmaengine: fsl_raid: check fsl_re_chan_probe() return value

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

Pre-existing issues:
- [High] The driver never frees requested IRQs or unregisters child platform devices, causing resource leaks and use-after-free on error paths and driver unbind.
- [High] Returning an error from `dma_async_device_register()` or early returns in `fsl_re_probe()` fail to unwind successfully probed channels, causing resource leaks and UAF.
- [High] DMA channels are never added to the DMA device channels list, rendering the driver non-functional.
- [High] Interrupt is requested before private data and hardware are fully initialized, risking a NULL pointer dereference in the interrupt handler.
- [High] Channel resources are destroyed before the DMA device is unregistered, allowing concurrent use-after-free.
--

commit df14fae70b7983f30255454748eb310d0c4f9ad9
Author: Rosen Penev [off-list ref]

dmaengine: fsl_raid: check fsl_re_chan_probe() return value

The commit fixes a potential NULL pointer dereference in fsl_re_remove_chan()
by checking the return value of fsl_re_chan_probe() during device probe and
guarding against NULL entries during removal.

[Severity: High]
This is a pre-existing issue, but does fsl_re_chan_probe() leak resources on
failure and driver unbind?

In fsl_re_chan_probe(), a platform device is created and an interrupt is
requested without devres management:

    chan_ofdev = of_platform_device_create(np, NULL, dev);
    ...
    ret = request_irq(chan->irq, fsl_re_isr, 0, chan->name, chandev);

The error path just returns without unwinding these:

err_free:
    return ret;

Furthermore, fsl_re_remove_chan() destroys the tasklet but does not free the
interrupt or unregister the child device. Since devres will automatically free
the chan structure on unbind, wouldn't the leaked active interrupt cause a
use-after-free if it fires and accesses the freed chan structure?

[Severity: High]
This is another pre-existing issue, but are the channels ever linked to the
device's channels list?

fsl_re_chan_probe() sets the device pointer:

    chan->chan.device = dma_dev;
    chan->chan.private = chan;

However, it seems to miss linking the channel into the parent device's
channel list. When dma_async_device_register() is called later, wouldn't it
see an empty channels list and register zero channels, rendering the driver
non-functional?

[Severity: High]
This is a pre-existing issue, but is there a race condition between requesting
the interrupt and setting the driver data?

fsl_re_chan_probe() requests the interrupt before setting the driver data:

    ret = request_irq(chan->irq, fsl_re_isr, 0, chan->name, chandev);
    ...
    dev_set_drvdata(chandev, chan);

If the interrupt fires in this window, fsl_re_isr() will read a NULL pointer
from dev_get_drvdata() and unconditionally dereference it:

    re_chan = dev_get_drvdata((struct device *)data);
    irqstate = in_be32(&re_chan->jrregs->jr_interrupt_status);

Can this lead to a NULL pointer dereference panic?

 			if (rc) {
-				fsl_re_chan_probe(ofdev, child, ridx++, off);
-				re_priv->total_chans++;
+				dev_err(dev,
+					"job ring %d probe failed: %d\n",
+					ridx, rc);
+				continue;
 			}
+			ridx++;
+			re_priv->total_chans++;
 		}
 	}
 
-	dma_async_device_register(dma_dev);
-
-	return 0;
+	return dma_async_device_register(dma_dev);

[Severity: High]
This is a pre-existing issue, but if dma_async_device_register() fails, are
the successfully probed channels abandoned?

When dma_async_device_register() returns an error, the function exits without
calling fsl_re_remove() to clean up any channels initialized during earlier
job queue iterations.

Since the interrupts for these channels are not devres-managed, they would
remain active. Once devres frees the associated chan memory, could an
interrupt firing trigger a use-after-free crash?

[Severity: High]
This is a pre-existing issue, but are channel resources destroyed prematurely
during driver unbind?

fsl_re_remove_chan() is called for each channel, killing tasklets and freeing
dma pools:

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

Afterward, the device is unregistered:

    dma_async_device_unregister(&re_priv->dma_dev);

Since the subsystem still considers the device active until unregistration
completes, could concurrent or pending requests attempt to use the already
freed pools or schedule the killed tasklets?

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