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

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

Pre-existing issues:
- [Critical] The asynchronous worker `esparser_queue_work` is scheduled but never explicitly canceled, leading to a Use-After-Free when the file descriptor is closed.
- [High] Potential NULL pointer dereference when accessing `of_id->data` if `of_match_node()` returns NULL.
- [High] Missing cleanup of V4L2 control handler in the session release path causes a memory leak.
- [High] Early IRQ request allows spurious or pending interrupts to dereference a NULL `core->cur_sess`.
--

--- Patch [1]: [PATCH] staging: media: meson: vdec: propagate devm_clk_get() errors ---
commit e254e1429efee5a0b94f582e6b31b4ef82669c9a
Author: Alfie Varghese <[email protected]>

staging: media: meson: vdec: propagate devm_clk_get() errors

This commit modifies vdec_probe() to propagate actual error codes returned
by devm_clk_get() instead of hardcoding -EPROBE_DEFER. It prevents the
driver core from retrying probes indefinitely when encountering real
errors like -ENOMEM or -ENOENT.

> 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 is a pre-existing issue, but does this code handle the case where
of_match_node() returns NULL? If the driver is bound manually via sysfs
to a platform device lacking a device tree node, of_match_node()
returns NULL.

drivers/staging/media/meson/vdec/vdec.c:vdec_probe() {
    ...
    of_id = of_match_node(vdec_dt_match, dev->of_node);
    core->platform = of_id->data;
    ...
}

Could this lead to a NULL pointer dereference when accessing of_id->data?

>  	    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 is it safe to request the IRQ before
the session state is initialized?

drivers/staging/media/meson/vdec/vdec.c:vdec_probe() {
    ...
    ret = devm_request_threaded_irq(core->dev, irq, vdec_isr,
                                    vdec_threaded_isr, IRQF_ONESHOT,
                                    "vdec", core);
    ...
}

If a spurious interrupt or a pending interrupt from the bootloader fires
immediately, the ISR dereferences core->cur_sess:

drivers/staging/media/meson/vdec/vdec.c:vdec_isr() {
    ...
    struct amvdec_session *sess = core->cur_sess;

    sess->last_irq_jiffies = get_jiffies_64();
    ...
}

Will this cause a NULL pointer dereference since the session state isn't
established until later?

[Severity: Critical]
This isn't a bug introduced by this patch, but is there a use-after-free
risk when the file descriptor is closed?

If userspace queues a buffer (which schedules sess->esparser_queue_work)
and immediately closes the file descriptor, vdec_close() frees the
session context without syncing:

drivers/staging/media/meson/vdec/vdec.c:vdec_close() {
    ...
    kfree(sess);
    ...
}

However, the asynchronous worker doesn't appear to be explicitly
canceled with cancel_work_sync(), and might dereference the freed
pointer:

drivers/staging/media/meson/vdec/esparser.c:esparser_queue_all_src() {
    ...
    struct amvdec_session *sess =
        container_of(work, struct amvdec_session, esparser_queue_work);

    mutex_lock(&sess->lock);
    ...
}

Can this lead to memory corruption if the worker runs after the release?

[Severity: High]
This is a pre-existing issue, but does vdec_close() properly clean up
the V4L2 control handler?

The handler is initialized via v4l2_ctrl_handler_init() during open,
allocating internal control structures, but vdec_close() seems to omit
the corresponding teardown call before freeing the session context:

drivers/staging/media/meson/vdec/vdec.c:vdec_close() {
    ...
    kfree(sess);
    ...
}

If an unprivileged user repeatedly opens and closes the device, could
this leak kernel memory and eventually cause an out-of-memory condition?

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

_______________________________________________
linux-amlogic mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-amlogic