Re: [PATCH v8 01/12] media: iris: Add iris vpu bus support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unsafe lifetime assumption for `platform_data` exposes a use-after-free vulnerability during IOMMU deferred probing.
--

commit 9a991f2d1e4dce862e38d602c5406c132a0d5307
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

media: iris: Add iris vpu bus support

On glymur platform, firmware loading needs a separate IOMMU mapping with
its own stream ID. This stream ID is defined in the device tree with the
associated firmware function ID in the iommu-map property. To create this
mapping, a separate child device is needed so the firmware memory can be
isolated in its own IOMMU context.

> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_bus.c b/drivers/media/platform/qcom/iris/iris_vpu_bus.c
> new file mode 100644
> index 0000000000000..e3327b227332a
> --- /dev/null
> +++ b/drivers/media/platform/qcom/iris/iris_vpu_bus.c
> @@ -0,0 +1,61 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/iris_vpu_bus.h>
> +#include <linux/of_device.h>
> +#include <linux/slab.h>
> +
> +static int iris_vpu_bus_dma_configure(struct device *dev)
> +{
> +	const u32 *iommu_fid = (const u32 *)dev_get_platdata(dev);
> +
> +	return of_dma_configure_id(dev, dev->parent->of_node, true, iommu_fid);
> +}

[ ... ]

> +struct device *iris_vpu_bus_create_device(struct device *parent_device, const char *name,
> +					  u64 dma_mask, const u32 *iommu_fid)
> +{
> +	struct device *dev;
> +	int ret;
> +
> +	dev = kzalloc_obj(*dev);
> +	if (!dev)
> +		return ERR_PTR(-ENOMEM);
> +
> +	dev->release = iris_vpu_bus_release_device;
> +	dev->bus = &iris_vpu_bus_type;
> +	dev->parent = parent_device;
> +	dev->coherent_dma_mask = dma_mask;
> +	dev->dma_mask = &dev->coherent_dma_mask;
> +	dev->platform_data = (void *)iommu_fid;

[Severity: High]
Does this create a use-after-free risk during deferred probing?

If the caller (such as iris_glymur_init_cb_devs()) passes a pointer to a
local stack variable, and the IOMMU driver defers probe,
iris_vpu_bus_dma_configure() will be called again asynchronously when the
IOMMU driver initializes.

Since we store the raw pointer here instead of taking the value or copying
the data, could of_dma_configure_id() dereference invalid stack memory if
the caller's stack frame has already been popped?

> +	dev_set_name(dev, "%s", name);
> +
> +	ret = device_register(dev);
> +	if (ret) {
> +		put_device(dev);
> +		return ERR_PTR(ret);
> +	}
> +
> +	return dev;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-glymur-v8-0-1c79b9d51fc0@oss.qualcomm.com?part=1