All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mukesh Ojha" <mukesh.ojha@oss.qualcomm.com>
Cc: media-ci@linuxtv.org, linux-sunxi@lists.linux.dev
Subject: Re: [PATCH v2 5/6] media: mediatek: vpu: Use devm_of_reserved_mem_device_init()
Date: Wed, 02 Sep 2026 20:17:59 +0000	[thread overview]
Message-ID: <20260902201800.5822B1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260902200703.2016410-6-mukesh.ojha@oss.qualcomm.com>

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

Pre-existing issues:
- [High] Pre-existing race condition leading to a use-after-free. The driver uses `devm_request_irq()` to manage its interrupt, but manually destroys the workqueue (`vpu->wdt.wq`) in `mtk_vpu_remove()`. Because devres cleans up the IRQ only after `remove()` completes, the interrupt remains active while the workqueue is freed.
--

commit 246438dea9de2810275787060608206f1c3a4872
Author: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>

media: mediatek: vpu: Use devm_of_reserved_mem_device_init()

This patch simplifies the driver by replacing manual
of_reserved_mem_device_init() and of_reserved_mem_device_release()
calls with the managed devm_of_reserved_mem_device_init() equivalent.

> diff --git a/drivers/media/platform/mediatek/vpu/mtk_vpu.c b/drivers/media/platform/mediatek/vpu/mtk_vpu.c
> --- a/drivers/media/platform/mediatek/vpu/mtk_vpu.c
> +++ b/drivers/media/platform/mediatek/vpu/mtk_vpu.c
[ ... ]
> @@ -930,7 +930,6 @@ static int mtk_vpu_probe(struct platform_device *pdev)
>  free_d_mem:
>  	vpu_free_ext_mem(vpu, D_FW);
>  remove_debugfs:
> -	of_reserved_mem_device_release(dev);

[Severity: High]
This is a pre-existing issue, but while reviewing this devres conversion, I
noticed a potential use-after-free race condition related to device teardown.

In mtk_vpu_probe(), the interrupt is registered as managed using
devm_request_irq(), meaning it will remain active until devres cleanup runs
after mtk_vpu_remove() completes.

However, the workqueue is manually destroyed during mtk_vpu_remove():

drivers/media/platform/mediatek/vpu/mtk_vpu.c:mtk_vpu_remove() {
    ...
    if (vpu->wdt.wq)
        destroy_workqueue(vpu->wdt.wq);
    ...
}

If a hardware interrupt fires after destroy_workqueue() executes but before
the devres cleanup disables the IRQ, vpu_irq_handler() will attempt to
access the freed workqueue structure:

drivers/media/platform/mediatek/vpu/mtk_vpu.c:vpu_irq_handler() {
    ...
    queue_work(vpu->wdt.wq, &vpu->wdt.ws);
    ...
}

Can this sequence cause a use-after-free if the hardware triggers an
interrupt late during the unbind process?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902200703.2016410-1-mukesh.ojha@oss.qualcomm.com?part=5

  reply	other threads:[~2026-09-02 20:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 20:06 [PATCH v2 0/6] media: Use devm_of_reserved_mem_device_init() Mukesh Ojha
2026-09-02 20:06 ` [PATCH v2 1/6] media: synopsys: hdmirx: " Mukesh Ojha
2026-09-02 20:15   ` sashiko-bot
2026-09-02 20:06 ` [PATCH v2 2/6] media: aspeed: " Mukesh Ojha
2026-09-02 20:19   ` sashiko-bot
2026-09-02 20:07 ` [PATCH v2 3/6] media: nuvoton: npcm-video: " Mukesh Ojha
2026-09-02 20:17   ` sashiko-bot
2026-09-02 20:07 ` [PATCH v2 4/6] media: arm: mali-c55: " Mukesh Ojha
2026-09-02 20:19   ` sashiko-bot
2026-09-02 20:07 ` [PATCH v2 5/6] media: mediatek: vpu: " Mukesh Ojha
2026-09-02 20:17   ` sashiko-bot [this message]
2026-09-03  3:08   ` Chen-Yu Tsai
2026-09-02 20:07 ` [PATCH v2 6/6] staging: media: cedrus: " Mukesh Ojha
2026-09-02 20:26   ` sashiko-bot

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=20260902201800.5822B1F00A3D@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=media-ci@linuxtv.org \
    --cc=mukesh.ojha@oss.qualcomm.com \
    --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.