[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b5f9d751-5425-4281-8a21-99e92bd447b7@xs4all.nl>
Date: Tue, 7 Nov 2023 11:14:34 +0100
From: Hans Verkuil <hverkuil@...all.nl>
To: Zheng Wang <zyytlz.wz@....com>, dmitry.osipenko@...labora.com
Cc: Kyrie.Wu@...iatek.com, bin.liu@...iatek.com, mchehab@...nel.org,
matthias.bgg@...il.com, angelogioacchino.delregno@...labora.com,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org, Irui.Wang@...iatek.com,
security@...nel.org, hackerzheng666@...il.com,
amergnat@...libre.com, wenst@...omium.org, stable@...r.kernel.org
Subject: Re: [RESEND PATCH v2 0/3] Fix use-after-free bug in
mtk_jpeg_dec_device_run and fix schedule error in mtk_jpegdec_worker
On 06/11/2023 15:48, Zheng Wang wrote:
> Hello,
>
> This v2 series fixes the use-after-free bug in mtk_jpeg_dec_device_run.
> This patch fixes the security bug in chrome-os.
> It inclues reverting the incomplete fix before and make the right fix.
> Also,it fixes the error of timeout-worker-schedule in multiple-core
> devices.
>
> 1. Remove cancel worker in mtk_jpeg_remove for the worker is only
> registered in single-core device but we try to cacnel it in both
> single-core and multiple-core devices.
>
> 2. Fix use-after-free bug by delay the schedule_delayed_work only if
> mtk_jpeg_set_dec_dst runs successfully.
>
> 3. Delay the schedule_delayed_work in mtk_jpegdec_worker as it has same
> code logic in mtk_jpeg_dec_device_run.
>
> version 2 changes
>
> -put the patches into on series suggested by Dmitry
>
> Zheng Wang (3):
> media: mtk-jpeg: Remove cancel worker in mtk_jpeg_remove to avoid the
> crash of multi-core JPEG devices
> media: mtk-jpeg: Fix use after free bug due to error path handling
> in mtk_jpeg_dec_device_run
> media: mtk-jpeg: Fix timeout schedule error in mtk_jpegdec_worker.
>
> .../media/platform/mediatek/jpeg/mtk_jpeg_core.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
Please don't resend. If it is in patchwork.linuxtv.org then it is good.
Fixes (unless they fix something really nasty) can take several weeks before
they are picked up. I usually schedule 2 or 3 rounds per kernel cycle where
I go through all the pending patches with fixes.
Regards,
Hans
Powered by blists - more mailing lists