[PATCH v2] staging: media: meson: vdec: propagate devm_clk_get() errors

[sashiko-bot at kernel.org]

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

Pre-existing issues:
- [High] The interrupt handlers `vdec_isr` and `vdec_threaded_isr` will dereference a NULL `core->cur_sess` if triggered early.
- [High] `meson_canvas_get()` does not establish a device link, leading to a potential Use-After-Free if the canvas driver is unbound.
--

--- Patch [1]: [PATCH v2] staging: media: meson: vdec: propagate devm_clk_get() errors ---
commit 7a1b822824f968330db11f53c7acb92d01abc7a0
Author: Alfie Varghese <alfievarghese22 at gmail.com>

staging: media: meson: vdec: propagate devm_clk_get() errors
    
vdec_probe() hardcodes -EPROBE_DEFER for all devm_clk_get() failures.
This masks the actual error code returned by the clock framework, such
as -ENOENT when a clock is not registered or -ENOMEM on allocation
failure.

> diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/media/meson/vdec/vdec.c
> index a039d925c0fe5..fba1e7f88d81f 100644
> --- a/drivers/staging/media/meson/vdec/vdec.c
> +++ b/drivers/staging/media/meson/vdec/vdec.c
> @@ -1026,24 +1026,24 @@ static int vdec_probe(struct platform_device *pdev)

[Severity: High]
This isn't a bug introduced by this patch, but does the canvas handling
risk a use-after-free?

In vdec_probe(), the driver retrieves the canvas provider via
meson_canvas_get() slightly earlier in the function. Looking at
meson_canvas_get() in meson-canvas.c:

drivers/soc/amlogic/meson-canvas.c:meson_canvas_get() {
    ...
    canvas = dev_get_drvdata(&canvas_pdev->dev);
    put_device(&canvas_pdev->dev);
    return canvas;
}

Since the device reference is dropped immediately before returning and no
device link is established using device_link_add(), couldn't a user unbind
the amlogic-canvas driver via sysfs, freeing the canvas memory while the
active vdec driver still relies on core->canvas?

>  	    core->platform->revision == VDEC_REVISION_SM1) {
>  		core->vdec_hevcf_clk = devm_clk_get(dev, "vdec_hevcf");
>  		if (IS_ERR(core->vdec_hevcf_clk))
> -			return -EPROBE_DEFER;
> +			return PTR_ERR(core->vdec_hevcf_clk);
>  	}

[ ... ]

>  	core->vdec_hevc_clk = devm_clk_get(dev, "vdec_hevc");
>  	if (IS_ERR(core->vdec_hevc_clk))
> -		return -EPROBE_DEFER;
> +		return PTR_ERR(core->vdec_hevc_clk);
>  
>  	irq = platform_get_irq_byname(pdev, "vdec");
>  	if (irq < 0)

[Severity: High]
This is a pre-existing issue, but can this code trigger a NULL pointer
dereference in the interrupt handler?

Right after retrieving the IRQ in vdec_probe(), the hardware interrupt is
registered via devm_request_threaded_irq() before explicitly masking
interrupts on the device hardware and before allocating a session.

If the bootloader left the video decoder active, or if a spurious interrupt
fires immediately after registration, vdec_isr() would execute:

drivers/staging/media/meson/vdec/vdec.c:vdec_isr() {
    ...
    sess = core->cur_sess;
    sess->last_irq_jiffies = get_jiffies_64();
    ...
}

Since core->cur_sess remains NULL until a userspace client opens the device
and starts streaming, wouldn't this crash the kernel? Is it possible to
disable hardware interrupts prior to IRQ registration, or check for a NULL
session in the ISR?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714140458.1276-1-alfievarghese22@gmail.com?part=1