All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Alfie Varghese" <alfievarghese22@gmail.com>
Cc: neil.armstrong@linaro.org, linux-amlogic@lists.infradead.org,
	media-ci@linuxtv.org
Subject: Re: [PATCH v3] staging: media: meson: vdec: propagate devm_clk_get() errors
Date: Fri, 17 Jul 2026 03:15:32 +0000	[thread overview]
Message-ID: <20260717031532.ED9D71F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260717030559.167-1-alfievarghese22@gmail.com>

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

Pre-existing issues:
- [Critical] The driver holds an unpinned pointer to the `amlogic-canvas` provider, leading to a Use-After-Free vulnerability if the canvas driver is unbound.
- [High] The `vdec_isr` and `vdec_threaded_isr` interrupt handlers unconditionally dereference `core->cur_sess`. If an interrupt fires immediately upon registration (e.g., left pending by the bootloader), this will cause a fatal NULL pointer dereference because `core->cur_sess` is initialized to `NULL`.
--

--- Patch [1]: [PATCH v3] staging: media: meson: vdec: propagate devm_clk_get() errors ---
commit 9a8ffbf8f058a33cad3c2292a9632f5eb5e8f843
Author: Alfie Varghese <alfievarghese22@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. Return PTR_ERR() instead to propagate the real error to the
caller.

> 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)
[ ... ]
>  	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: Critical]
This is a pre-existing issue, but earlier in vdec_probe() we store a pointer
to the canvas device:

	core->canvas = meson_canvas_get(dev);

Looking at drivers/soc/amlogic/meson-canvas.c:meson_canvas_get(), the
function drops the reference to the canvas device before returning the
driver data pointer:

	canvas = dev_get_drvdata(&canvas_pdev->dev);
	put_device(&canvas_pdev->dev);
	if (!canvas)
		return ERR_PTR(-EINVAL);

	return canvas;

Since there is no device link and no reference is held, is it possible for
the amlogic-canvas device to be freely unbound via sysfs, freeing the canvas
structure? 

If the vdec driver later attempts a video decoding operation, might it access
the freed memory and result in a use-after-free?

[Severity: High]
This isn't a bug introduced by this patch, but just below the modified code we
request the interrupt without IRQF_NO_AUTOEN:

	ret = devm_request_threaded_irq(core->dev, irq, vdec_isr,
					vdec_threaded_isr, IRQF_ONESHOT,
					"vdec", core);

If there is a pending interrupt left over by the bootloader, it might fire
immediately upon registration. The interrupt handler vdec_isr()
unconditionally dereferences core->cur_sess:

	struct amvdec_session *sess = core->cur_sess;
	sess->last_irq_jiffies = get_jiffies_64();

Since core->cur_sess is initialized to NULL and only assigned later during
streaming, will this lead to a NULL pointer dereference? 

Would it be safer to add the IRQF_NO_AUTOEN flag when registering this
interrupt?

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

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

  reply	other threads:[~2026-07-17  3:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-17  3:05 [PATCH v3] staging: media: meson: vdec: propagate devm_clk_get() errors Alfie Varghese
2026-07-17  3:05 ` Alfie Varghese
2026-07-17  3:15 ` sashiko-bot [this message]
2026-07-17  5:51 ` Dan Carpenter
2026-07-17  5:51   ` Dan Carpenter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260717031532.ED9D71F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=alfievarghese22@gmail.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=media-ci@linuxtv.org \
    --cc=neil.armstrong@linaro.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.