From: Guangshuo Li <lgs201920130244@gmail.com>
To: Bin Liu <bin.liu@mediatek.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Nicolas Dufresne <nicolas.dufresne@collabora.com>,
Fan Wu <fanwu01@zju.edu.cn>,
Hans Verkuil <hverkuil+cisco@kernel.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Cc: Guangshuo Li <lgs201920130244@gmail.com>
Subject: [PATCH] media: mtk-jpeg: drain hardware completion before freeing context
Date: Wed, 8 Jul 2026 20:08:33 +0800 [thread overview]
Message-ID: <20260708120833.755998-1-lgs201920130244@gmail.com> (raw)
The change referenced by the Fixes tag cancels ctx->jpeg_work before
freeing the JPEG context from mtk_jpeg_release().
That prevents a queued or running JPEG worker from dereferencing the
context after it has been freed. However, on multi-core hardware the
worker can program a hardware instance, arm the per-hardware timeout
work, store the context in hw_param.curr_ctx and then return while the
hardware completion is still pending.
In that state cancel_work_sync(&ctx->jpeg_work) can complete even though
the IRQ handler or timeout work can still recover the same context from
hw_param.curr_ctx. If userspace closes the file before the hardware
completion path has run, release can free the context and a later IRQ or
timeout work can dereference the freed ctx while updating the done queues.
Drain the in-flight hardware completion state associated with the context
before freeing it.
Fixes: 34c519feef3e ("media: mtk-jpeg: fix use-after-free in release path due to uncancelled work")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index d147ec483081..bc9eea0483ce 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1202,8 +1202,11 @@ static int mtk_jpeg_release(struct file *file)
struct mtk_jpeg_dev *jpeg = video_drvdata(file);
struct mtk_jpeg_ctx *ctx = mtk_jpeg_file_to_ctx(file);
- if (jpeg->variant->jpeg_worker)
+ if (jpeg->variant->jpeg_worker) {
cancel_work_sync(&ctx->jpeg_work);
+ mtk_jpeg_release_hw(jpeg, ctx);
+ }
+
mutex_lock(&jpeg->lock);
v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
v4l2_ctrl_handler_free(&ctx->ctrl_hdl);
--
2.43.0
reply other threads:[~2026-07-08 12:08 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260708120833.755998-1-lgs201920130244@gmail.com \
--to=lgs201920130244@gmail.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=bin.liu@mediatek.com \
--cc=fanwu01@zju.edu.cn \
--cc=hverkuil+cisco@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=mchehab@kernel.org \
--cc=nicolas.dufresne@collabora.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox