dmaengine: mv_xor: kill tasklet on channel add error path

drivers/dma/mv_xor.c mv_xor_channel_add(struct mv_xor_device *xordev, · line 1168

drivers/dma/mv_xor.c:mv_xor_channel_remove() {
...

	dma_free_wc(dev, MV_XOR_POOL_SIZE,
			  mv_chan->dma_desc_pool_virt, mv_chan->dma_desc_pool);
...
	free_irq(mv_chan->irq, mv_chan);

	return 0;
}

[Severity: High]
This problem wasn't introduced by this patch, but in mv_xor_channel_remove(), the teardown order is incorrect (dma_free_wc is called before free_irq) and tasklet_kill() is entirely missing.

Since this patch fixes a similar issue in mv_xor_channel_add(), does mv_xor_channel_remove() also need tasklet_kill() and reordered teardown to avoid tasklet leaks and use-after-free bugs? If a tasklet is scheduled before or during free_irq(), could it remain alive after mv_chan is freed by devres, leading to a use-after-free? Alternatively, if an interrupt fires after dma_free_wc() but before free_irq(), will it access freed DMA descriptor memory?

drivers/dma/mv_xor.c:mv_xor_channel_add() {
...

	ret = request_irq(mv_chan->irq, mv_xor_interrupt_handler,
			  0, dev_name(&pdev->dev), mv_chan);
	if (ret)
		goto err_free_dma;

	mv_chan_unmask_interrupts(mv_chan);
...
	spin_lock_init(&mv_chan->lock);
	INIT_LIST_HEAD(&mv_chan->chain);
	INIT_LIST_HEAD(&mv_chan->completed_slots);

...
}

[Severity: High]
This problem wasn't introduced by this patch, but in mv_xor_channel_add(), request_irq() is called and unmasked before spinlocks and lists are initialized.

Does this create a race window that can crash the kernel? If an interrupt fires immediately upon being unmasked, could the interrupt handler schedule the IRQ tasklet, which then attempts to acquire an uninitialized lock and traverse uninitialized lists, resulting in a null pointer dereference or kernel panic?

drivers/dma/mv_xor.c:
...

static struct platform_driver mv_xor_driver = {
	.probe		= mv_xor_probe,
	.suspend        = mv_xor_suspend,
	.resume         = mv_xor_resume,
	.driver		= {

...
}

[Severity: High]
This problem wasn't introduced by this patch, but does the missing .remove callback in the platform driver leak non-devres resources and cause a use-after-free upon sysfs unbind?

Unbinding the driver via sysfs causes devres_release_all() to free devm-managed resources like mv_chan. However, explicitly allocated non-devres resources like request_irq(), dma_alloc_wc(), and dma_async_device_register() are never released. If an interrupt fires later, will it dereference the devres-freed mv_chan?

drivers/dma/mv_xor.c:mv_chan_memcpy_self_test() {
...

	if (mv_xor_status(dma_chan, cookie, NULL) !=
	    DMA_COMPLETE) {
		dev_err(dma_chan->device->dev,
			"Self-test copy timed out, disabling\n");
		err = -ENODEV;
		goto free_resources;
	}
...
free_resources:
	dmaengine_unmap_put(unmap);
	mv_xor_free_chan_resources(dma_chan);
out:
	kfree(src);
	kfree(dest);

...
}

[Severity: Critical]
This problem wasn't introduced by this patch, but do the self-test timeout error paths unmap and free DMA memory without terminating the active hardware transfer?

If the hardware was merely delayed, could it eventually complete the transfer and perform DMA writes into the kfree'd memory? If this memory has been reallocated to another subsystem, would this cause silent memory corruption?

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1