[RFC PATCH 0/1] dmaengine: apple-admac: should manual unbind be disabled?

[RFC PATCH 0/1] dmaengine: apple-admac: should manual unbind be disabled?

[Fan Wu]

This RFC asks whether manual unbind of the apple-admac DMA controller
should be disabled.

apple-admac stores its dma_device and channels in devm-managed memory and
does not implement dma_device.device_release. At registration, the
DMAengine core emits a diagnostic that the driver is not safe to unbind
while in use, and on channel unregister it emits WARN_ONCE if a channel
still has clients. admac_data is released by devres after admac_remove()
returns, so if a client still holds a channel at that point it may
reference the freed dma_chan and admac_data.

As the controller is a fixed SoC resource, the patch removes the standard
driver-core sysfs bind/unbind controls. It also opts the driver out of
CONFIG_DEBUG_TEST_DRIVER_REMOVE.

This RFC does not define behavior for other removal paths, such as
device or DT-overlay removal. Guidance is requested on whether this
restriction is appropriate, or whether the driver should retain manual
bind/unbind support.

This issue was found by an in-house static analysis tool.


Fan Wu (1):
  dmaengine: apple-admac: suppress bind/unbind sysfs attributes

 drivers/dma/apple-admac.c | 1 +
 1 file changed, 1 insertion(+)

--
2.34.1

[RFC PATCH 1/1] dmaengine: apple-admac: suppress bind/unbind sysfs attributes

[Fan Wu]

apple-admac stores its dma_device and channels in devm-managed memory and
does not implement dma_device.device_release. At registration, the
DMAengine core emits a diagnostic that the driver is not safe to unbind
while in use, and on channel unregister it emits WARN_ONCE if a channel
still has clients. admac_data is released by devres after admac_remove()
returns, so if a client still holds a channel at that point it may
reference the freed dma_chan and admac_data.

As the controller is a fixed SoC resource, remove the standard
driver-core sysfs bind/unbind controls. It also opts the driver out of
CONFIG_DEBUG_TEST_DRIVER_REMOVE.

This RFC does not define behavior for other removal paths, such as
device or DT-overlay removal. Guidance is requested on whether this
restriction is appropriate, or whether the driver should retain manual
bind/unbind support.

This issue was found by an in-house static analysis tool.

Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
---
 drivers/dma/apple-admac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/apple-admac.c b/drivers/dma/apple-admac.c
index 04bbd774b3b4..b448ee323454 100644
--- a/drivers/dma/apple-admac.c
+++ b/drivers/dma/apple-admac.c
@@ -946,6 +946,7 @@ static struct platform_driver apple_admac_driver = {
 	.driver = {
 		.name = "apple-admac",
 		.of_match_table = admac_of_match,
+		.suppress_bind_attrs = true,
 	},
 	.probe = admac_probe,
 	.remove = admac_remove,
--
2.34.1

Re: [RFC PATCH 1/1] dmaengine: apple-admac: suppress bind/unbind sysfs attributes

[sashiko-bot]

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

Pre-existing issues:
- [High] Use-After-Free and unmapped MMIO access due to lack of `dma_device.device_release` and relying on devres for memory management.
- [High] Use-After-Free due to missing tasklet teardown in device removal.
- [High] Out-of-bounds DMA transfers due to missing alignment validation in `admac_prep_dma_cyclic`.
- [High] DMA hardware state machine is not stopped during device removal, leading to memory corruption.
--

--- Patch [1]: [RFC PATCH 1/1] dmaengine: apple-admac: suppress bind/unbind sysfs attributes ---
commit f71ce7adaa3454720893d7cb49e38df7126d9fe4
Author: Fan Wu <fanwu01@zju.edu.cn>

dmaengine: apple-admac: suppress bind/unbind sysfs attributes

apple-admac stores its dma_device and channels in devm-managed memory and
does not implement dma_device.device_release. This patch suppresses sysfs
bind/unbind controls since unbinding while in use causes memory corruption.

> diff --git a/drivers/dma/apple-admac.c b/drivers/dma/apple-admac.c
> index 14a5ee14a4815..1f331bf051e16 100644
> --- a/drivers/dma/apple-admac.c
> +++ b/drivers/dma/apple-admac.c
> @@ -946,6 +946,7 @@ static struct platform_driver apple_admac_driver = {
>  	.driver = {
>  		.name = "apple-admac",
>  		.of_match_table = admac_of_match,
> +		.suppress_bind_attrs = true,
>  	},
>  	.probe = admac_probe,

[Severity: High]
This is a pre-existing issue, but does relying on devm_kzalloc() for
admac_data in admac_probe() lead to a use-after-free during device unbind?

If a client requests a DMA channel and the device is forcibly unbound,
devres will immediately free admac_data and its channels after
admac_remove() returns.

If the client later calls dma_release_channel(), won't it access the freed
admac_chan and call admac_free_chan_resources(), touching unmapped MMIO?

[Severity: High]
This isn't a bug introduced by this patch, but could an out-of-bounds issue
happen in admac_prep_dma_cyclic()?

drivers/dma/apple-admac.c:admac_prep_dma_cyclic() {
    ...
    adtx->buf_addr = buf_addr;
    adtx->buf_len = buf_len;
    adtx->buf_end = buf_addr + buf_len;
    adtx->period_len = period_len;
    ...
}

If a client passes a buf_len that is not a multiple of period_len, does
admac_cyclic_write_one_desc() calculate an offset that exceeds the buffer
bounds:

    addr = tx->buf_addr + (tx->submitted_pos % tx->buf_len);
    WARN_ON_ONCE(addr + tx->period_len > tx->buf_end);

and still program the hardware descriptors to perform out-of-bounds
transfers?

>  	.remove = admac_remove,

[Severity: High]
This is a pre-existing issue, but does admac_remove() fail to wait for or
kill scheduled tasklets?

If an interrupt fires and schedules a channel's tasklet concurrently with
device unbind, admac_remove() calls free_irq(), which doesn't wait for
tasklets to complete.

After admac_remove() returns and devres frees admac_data, could the tasklet
execute and dereference freed memory?

[Severity: High]
This is a pre-existing issue, but does admac_remove() leave the DMA
hardware active during unbind?

When the device is unregistered and memory is unmapped, if the hardware is
not commanded to stop (e.g., via admac_stop_chan or resetting rings), will
it continue performing DMA accesses to memory that may be freed by the
client, causing memory corruption?

>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260726052950.37062-2-fanwu01@zju.edu.cn?part=1