dmaengine: fsl_raid: zero CF descriptor pool allocations

drivers/dma/fsl_raid.c static struct fsl_re_desc *fsl_re_chan_alloc_desc(struct fsl_re_chan *re_chan, · line 298

[Severity: High]
This is a pre-existing issue, but when reusing a descriptor from free_q earlier in fsl_re_chan_alloc_desc(), does it leak residual state?

If a client allocates a descriptor, sets a callback, and executes it, the descriptor returns to free_q. When a subsequent client allocates from free_q:

drivers/dma/fsl_raid.c:fsl_re_chan_alloc_desc() {
    ...
    if (!list_empty(&re_chan->free_q)) {
        /* take one desc from free_q */
        desc = list_first_entry(&re_chan->free_q,
                    struct fsl_re_desc, node);
        list_del(&desc->node);

        desc->async_tx.flags = flags;
    }
    ...
}

Only async_tx.flags is updated here, leaving async_tx.callback and callback_param populated. Could this result in spurious callbacks being invoked with freed structures if the new transaction does not explicitly clear them?

drivers/dma/fsl_raid.c static int fsl_re_alloc_chan_resources(struct dma_chan *chan) · line 587

[Severity: High]
This isn't a bug introduced by this patch, but does the way alloc_count is tracked lead to integer underflow and list corruption in fsl_re_free_chan_resources()?

In fsl_re_free_chan_resources(), there is a blind loop:

drivers/dma/fsl_raid.c:fsl_re_free_chan_resources() {
    ...
    while (re_chan->alloc_count--) {
        desc = list_first_entry(&re_chan->free_q,
                    struct fsl_re_desc,
                    node);

        list_del(&desc->node);
    ...
}

If the channel is freed while any descriptors are still active (not in free_q), the loop will run more times than items exist in free_q. Would this result in list_first_entry() returning an invalid pointer and causing list corruption?

Additionally, if alloc_count reaches zero and the post-decrement underflows it to UINT_MAX, wouldn't subsequent calls to fsl_re_alloc_chan_resources() permanently break descriptor tracking when incrementing alloc_count?

[Severity: High]
This is a pre-existing issue, but could invoking client callbacks from fsl_re_dequeue() while holding desc_lock cause an AA deadlock?

drivers/dma/fsl_raid.c:fsl_re_dequeue() {
    ...
    spin_lock_irqsave(&re_chan->desc_lock, flags);
    count = FSL_RE_SLOT_FULL(in_be32(&re_chan->jrregs->oubring_slot_full));
    while (count--) {
        /* ... */
        if (found) {
            fsl_re_desc_done(desc);
    ...
}

The fsl_re_desc_done() function executes the client's completion callback. If the client submits a new transaction from within this callback, fsl_re_tx_submit() will attempt to acquire re_chan->desc_lock again. Does this result in a recursive spinlock deadlock?

[Severity: High]
This isn't a bug introduced by this patch, but does the driver fail to free its requested IRQ, potentially leading to a use-after-free?

In fsl_re_chan_probe(), an IRQ is requested without devm_:

drivers/dma/fsl_raid.c:fsl_re_chan_probe() {
    ...
    ret = request_irq(chan->irq, fsl_re_isr, 0, chan->name, chandev);
    if (ret) {
    ...
}

However, free_irq() does not appear to be called in the probe error paths or during driver removal in fsl_re_remove_chan(). If the device is removed, re_chan is freed via devm_kzalloc. If a subsequent hardware interrupt occurs, won't fsl_re_isr() attempt to dereference the freed re_chan pointer?

Also, in fsl_re_remove(), memory areas and tasklets are destroyed before the device is unregistered:

drivers/dma/fsl_raid.c:fsl_re_remove() {
    ...
    /* Cleanup chan related memory areas */
    for (i = 0; i < re_priv->total_chans; i++)
        fsl_re_remove_chan(re_priv->re_jrs[i]);

    /* Unregister the driver */
    dma_async_device_unregister(&re_priv->dma_dev);
    ...
}

Does this allow clients to still access DMA resources while they are being dismantled?