Re: [PATCH v8 11/19] dmaengine: ti: k3-udma: move inclusion of k3-udma-private.c to k3-udma-common.c

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

New issues:
- [High] Moving `xudma_*` exports to `k3-udma-common.c` severs the module dependency between the glue layer and the `k3-udma` driver, allowing trivial module unload and subsequent use-after-free.

Pre-existing issues:
- [High] `of_xudma_dev_get` returns a pointer to devres-managed memory without establishing a device link, allowing use-after-free via sysfs unbind.
--

--- Patch [11]: [PATCH v8 11/19] dmaengine: ti: k3-udma: move inclusion of k3-udma-private.c to k3-udma-common.c ---
commit d7f9cc34a06f8d7304b5d1021da68dd8f487667c
Author: Sai Sree Kartheek Adivi <[email protected]>

dmaengine: ti: k3-udma: move inclusion of k3-udma-private.c to k3-udma-common.c

This commit relocates the inclusion of k3-udma-private.c from k3-udma.c to
k3-udma-common.c to allow sharing the code with other udma variants.

> diff --git a/drivers/dma/ti/k3-udma-common.c b/drivers/dma/ti/k3-udma-common.c
> index b9d3cac5eb9d0..01b66e9f026b4 100644
> --- a/drivers/dma/ti/k3-udma-common.c
> +++ b/drivers/dma/ti/k3-udma-common.c
[ ... ]
> @@ -2535,3 +2535,6 @@ EXPORT_SYMBOL_GPL(k3_udma_setup_resources);
>  
>  MODULE_DESCRIPTION("Texas Instruments K3 UDMA Common Library");
>  MODULE_LICENSE("GPL v2");
> +
> +/* Private interfaces to UDMA */
> +#include "k3-udma-private.c"

[Severity: High]
Does moving this include introduce a regression by shifting the xudma_*
exports from the k3-udma module to the k3-udma-common module?

The k3-udma-glue.ko module bypasses the standard dma engine framework and
relies on these xudma_* functions. Previously, these functions were exported
by the k3-udma.ko driver, establishing a module dependency that prevented
k3-udma.ko from being unloaded while active.

By moving the exports to k3-udma-common.ko, k3-udma-glue.ko no longer holds
a reference to k3-udma.ko. If an administrator runs rmmod k3-udma, could it
successfully unbind the driver and free the devm-allocated struct udma_dev,
causing a use-after-free in the networking drivers on their next operation?

[Severity: High]
This is a pre-existing issue in k3-udma-private.c, but looking at how
of_xudma_dev_get() is implemented:

drivers/dma/ti/k3-udma-private.c:of_xudma_dev_get() {
    ...
    ud = platform_get_drvdata(pdev);
    put_device(&pdev->dev);
    if (!ud) {
    ...
}

Since of_xudma_dev_get() drops the device reference before returning the
pointer to the devres-managed struct udma_dev, and does not establish a
supplier-consumer relationship via device_link_add(), can this lead to a
use-after-free if a privileged user unbinds the driver via sysfs?

The driver core would be unaware of the glue layer's dependency, allowing the
unbind to succeed and free udma_dev while consumers hold a dangling pointer.

> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
> index 9a261747c8709..ddedd51ab26d9 100644
> --- a/drivers/dma/ti/k3-udma.c
> +++ b/drivers/dma/ti/k3-udma.c
[ ... ]
> @@ -2857,5 +2857,3 @@ module_platform_driver(udma_driver);
>  MODULE_DESCRIPTION("Texas Instruments UDMA support");
>  MODULE_LICENSE("GPL v2");
>  
> -/* Private interfaces to UDMA */
> -#include "k3-udma-private.c"

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