October 2023 - Linux-stable-mirror

[PATCH v2 2/3] media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run

by Zheng Wang

In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with mtk_jpeg_job_timeout_work. In mtk_jpeg_dec_device_run, if error happens in mtk_jpeg_set_dec_dst, it will finally start the worker while mark the job as finished by invoking v4l2_m2m_job_finish. There are two methods to trigger the bug. If we remove the module, it which will call mtk_jpeg_remove to make cleanup. The possible sequence is as follows, which will cause a use-after-free bug. CPU0 CPU1 mtk_jpeg_dec_... | start worker | |mtk_jpeg_job_timeout_work mtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use If we close the file descriptor, which will call mtk_jpeg_release, it will have a similar sequence. Fix this bug by starting timeout worker only if started jpegdec worker successfully. Then v4l2_m2m_job_finish will only be called in either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run. Fixes: b2f0d2724ba4 ("[media] vcodec: mediatek: Add Mediatek JPEG Decoder Driver") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> Cc: stable(a)vger.kernel.org --- v2: - put the patches into a single series suggested by Dmitry --- drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c index 60425c99a2b8..a39acde2724a 100644 --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c @@ -1021,13 +1021,13 @@ static void mtk_jpeg_dec_device_run(void *priv) if (ret < 0) goto dec_end; - schedule_delayed_work(&jpeg->job_timeout_work, - msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); - mtk_jpeg_set_dec_src(ctx, &src_buf->vb2_buf, &bs); if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, &dst_buf->vb2_buf, &fb)) goto dec_end; + schedule_delayed_work(&jpeg->job_timeout_work, + msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); + spin_lock_irqsave(&jpeg->hw_lock, flags); mtk_jpeg_dec_reset(jpeg->reg_base); mtk_jpeg_dec_set_config(jpeg->reg_base, -- 2.25.1

1 year, 2 months

1
0
0 0

[PATCH v2 3/3] media: mtk-jpeg: Fix timeout schedule error in

by Zheng Wang

In mtk_jpegdec_worker, if error occurs in mtk_jpeg_set_dec_dst, it will start the timeout worker and invoke v4l2_m2m_job_finish at the same time. This will break the logic of design for there should be only one function to call v4l2_m2m_job_finish. But now the timeout handler and mtk_jpegdec_worker will both invoke it. Fix it by start the worker only if mtk_jpeg_set_dec_dst successfully finished. Fixes: da4ede4b7fd6 ("media: mtk-jpeg: move data/code inside CONFIG_OF blocks") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> Cc: stable(a)vger.kernel.org --- v2: - put the patches into a single series suggested by Dmitry --- drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c index a39acde2724a..c3456c700c07 100644 --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c @@ -1749,9 +1749,6 @@ static void mtk_jpegdec_worker(struct work_struct *work) v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx); v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx); - schedule_delayed_work(&comp_jpeg[hw_id]->job_timeout_work, - msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); - mtk_jpeg_set_dec_src(ctx, &src_buf->vb2_buf, &bs); if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, @@ -1761,6 +1758,9 @@ static void mtk_jpegdec_worker(struct work_struct *work) goto setdst_end; } + schedule_delayed_work(&comp_jpeg[hw_id]->job_timeout_work, + msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); + spin_lock_irqsave(&comp_jpeg[hw_id]->hw_lock, flags); ctx->total_frame_num++; mtk_jpeg_dec_reset(comp_jpeg[hw_id]->reg_base); -- 2.25.1

1 year, 2 months

1
0
0 0

[PATCH v2 2/3] media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run

by Zheng Wang

In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with mtk_jpeg_job_timeout_work. In mtk_jpeg_dec_device_run, if error happens in mtk_jpeg_set_dec_dst, it will finally start the worker while mark the job as finished by invoking v4l2_m2m_job_finish. There are two methods to trigger the bug. If we remove the module, it which will call mtk_jpeg_remove to make cleanup. The possible sequence is as follows, which will cause a use-after-free bug. CPU0 CPU1 mtk_jpeg_dec_... | start worker | |mtk_jpeg_job_timeout_work mtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use If we close the file descriptor, which will call mtk_jpeg_release, it will have a similar sequence. Fix this bug by starting timeout worker only if started jpegdec worker successfully. Then v4l2_m2m_job_finish will only be called in either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run. Fixes: b2f0d2724ba4 ("[media] vcodec: mediatek: Add Mediatek JPEG Decoder Driver") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> Cc: stable(a)vger.kernel.org --- v2: - put the patches into a single series suggested by Dmitry --- drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c index 60425c99a2b8..a39acde2724a 100644 --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c @@ -1021,13 +1021,13 @@ static void mtk_jpeg_dec_device_run(void *priv) if (ret < 0) goto dec_end; - schedule_delayed_work(&jpeg->job_timeout_work, - msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); - mtk_jpeg_set_dec_src(ctx, &src_buf->vb2_buf, &bs); if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, &dst_buf->vb2_buf, &fb)) goto dec_end; + schedule_delayed_work(&jpeg->job_timeout_work, + msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); + spin_lock_irqsave(&jpeg->hw_lock, flags); mtk_jpeg_dec_reset(jpeg->reg_base); mtk_jpeg_dec_set_config(jpeg->reg_base, -- 2.25.1

1 year, 2 months

1
0
0 0

[PATCH v2 3/3] media: mtk-jpeg: Fix timeout schedule error in

by Zheng Wang

In mtk_jpegdec_worker, if error occurs in mtk_jpeg_set_dec_dst, it will start the timeout worker and invoke v4l2_m2m_job_finish at the same time. This will break the logic of design for there should be only one function to call v4l2_m2m_job_finish. But now the timeout handler and mtk_jpegdec_worker will both invoke it. Fix it by start the worker only if mtk_jpeg_set_dec_dst successfully finished. Fixes: da4ede4b7fd6 ("media: mtk-jpeg: move data/code inside CONFIG_OF blocks") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> Cc: stable(a)vger.kernel.org --- v2: - put the patches into a single series suggested by Dmitry --- drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c index a39acde2724a..c3456c700c07 100644 --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c @@ -1749,9 +1749,6 @@ static void mtk_jpegdec_worker(struct work_struct *work) v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx); v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx); - schedule_delayed_work(&comp_jpeg[hw_id]->job_timeout_work, - msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); - mtk_jpeg_set_dec_src(ctx, &src_buf->vb2_buf, &bs); if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, @@ -1761,6 +1758,9 @@ static void mtk_jpegdec_worker(struct work_struct *work) goto setdst_end; } + schedule_delayed_work(&comp_jpeg[hw_id]->job_timeout_work, + msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); + spin_lock_irqsave(&comp_jpeg[hw_id]->hw_lock, flags); ctx->total_frame_num++; mtk_jpeg_dec_reset(comp_jpeg[hw_id]->reg_base); -- 2.25.1

1 year, 2 months

1
0
0 0

[PATCH v2 2/3] media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run

by Zheng Wang

In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with mtk_jpeg_job_timeout_work. In mtk_jpeg_dec_device_run, if error happens in mtk_jpeg_set_dec_dst, it will finally start the worker while mark the job as finished by invoking v4l2_m2m_job_finish. There are two methods to trigger the bug. If we remove the module, it which will call mtk_jpeg_remove to make cleanup. The possible sequence is as follows, which will cause a use-after-free bug. CPU0 CPU1 mtk_jpeg_dec_... | start worker | |mtk_jpeg_job_timeout_work mtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use If we close the file descriptor, which will call mtk_jpeg_release, it will have a similar sequence. Fix this bug by starting timeout worker only if started jpegdec worker successfully. Then v4l2_m2m_job_finish will only be called in either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run. Fixes: b2f0d2724ba4 ("[media] vcodec: mediatek: Add Mediatek JPEG Decoder Driver") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> Cc: stable(a)vger.kernel.org --- v2: - put the patches into a single series suggested by Dmitry --- drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c index 60425c99a2b8..a39acde2724a 100644 --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c @@ -1021,13 +1021,13 @@ static void mtk_jpeg_dec_device_run(void *priv) if (ret < 0) goto dec_end; - schedule_delayed_work(&jpeg->job_timeout_work, - msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); - mtk_jpeg_set_dec_src(ctx, &src_buf->vb2_buf, &bs); if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, &dst_buf->vb2_buf, &fb)) goto dec_end; + schedule_delayed_work(&jpeg->job_timeout_work, + msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC)); + spin_lock_irqsave(&jpeg->hw_lock, flags); mtk_jpeg_dec_reset(jpeg->reg_base); mtk_jpeg_dec_set_config(jpeg->reg_base, -- 2.25.1

1 year, 2 months

1
0
0 0

Re: [PATCH v1] perf evlist: Avoid frequency mode for the dummy event

by Mingwei Zhang

On Mon, Oct 30, 2023 at 12:04 PM Mingwei Zhang <mizhang(a)google.com> wrote: > > On Fri, Sep 15, 2023 at 9:10 PM Ian Rogers <irogers(a)google.com> wrote: > > > > Dummy events are created with an attribute where the period and freq > > are zero. evsel__config will then see the uninitialized values and > > initialize them in evsel__default_freq_period. As fequency mode is > > used by default the dummy event would be set to use frequency > > mode. However, this has no effect on the dummy event but does cause > > unnecessary timers/interrupts. Avoid this overhead by setting the > > period to 1 for dummy events. > > > > evlist__add_aux_dummy calls evlist__add_dummy then sets freq=0 and > > period=1. This isn't necessary after this change and so the setting is > > removed. > > > > From Stephane: > > > > The dummy event is not counting anything. It is used to collect mmap > > records and avoid a race condition during the synthesize mmap phase of > > perf record. As such, it should not cause any overhead during active > > profiling. Yet, it did. Because of a bug the dummy event was > > programmed as a sampling event in frequency mode. Events in that mode > > incur more kernel overheads because on timer tick, the kernel has to > > look at the number of samples for each event and potentially adjust > > the sampling period to achieve the desired frequency. The dummy event > > was therefore adding a frequency event to task and ctx contexts we may > > otherwise not have any, e.g., perf record -a -e > > cpu/event=0x3c,period=10000000/. On each timer tick the > > perf_adjust_freq_unthr_context() is invoked and if ctx->nr_freq is > > non-zero, then the kernel will loop over ALL the events of the context > > looking for frequency mode ones. In doing, so it locks the context, > > and enable/disable the PMU of each hw event. If all the events of the > > context are in period mode, the kernel will have to traverse the list for > > nothing incurring overhead. The overhead is multiplied by a very large > > factor when this happens in a guest kernel. There is no need for the > > dummy event to be in frequency mode, it does not count anything and > > therefore should not cause extra overhead for no reason. > > > > Fixes: 5bae0250237f ("perf evlist: Introduce perf_evlist__new_dummy constructor") > > Reported-by: Stephane Eranian <eranian(a)google.com> > > Signed-off-by: Ian Rogers <irogers(a)google.com> > > --- > > tools/perf/util/evlist.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c > > index 25c3ebe2c2f5..e36da58522ef 100644 > > --- a/tools/perf/util/evlist.c > > +++ b/tools/perf/util/evlist.c > > @@ -251,6 +251,9 @@ static struct evsel *evlist__dummy_event(struct evlist *evlist) > > .type = PERF_TYPE_SOFTWARE, > > .config = PERF_COUNT_SW_DUMMY, > > .size = sizeof(attr), /* to capture ABI version */ > > + /* Avoid frequency mode for dummy events to avoid associated timers. */ > > + .freq = 0, > > + .sample_period = 1, > > }; > > > > return evsel__new_idx(&attr, evlist->core.nr_entries); > > @@ -277,8 +280,6 @@ struct evsel *evlist__add_aux_dummy(struct evlist *evlist, bool system_wide) > > evsel->core.attr.exclude_kernel = 1; > > evsel->core.attr.exclude_guest = 1; > > evsel->core.attr.exclude_hv = 1; > > - evsel->core.attr.freq = 0; > > - evsel->core.attr.sample_period = 1; > > evsel->core.system_wide = system_wide; > > evsel->no_aux_samples = true; > > evsel->name = strdup("dummy:u"); > > -- > > 2.42.0.459.ge4e396fd5e-goog > > > > Hi Greg, > > This patch is a critical performance fix for perf and vPMU. Can you > help us dispatch the commit to all stable kernel versions? > > Appreciate your help. Thanks. > -Mingwei Oops... Update target email to: stable(a)vger.kernel.org

1 year, 2 months

2
1
0 0

Re: Security Fix Backport: Intel RDMA driver

by Greg KH

On Mon, Oct 30, 2023 at 04:47:01PM +0000, Saleem, Shiraz wrote: > Hi, > > There was a security bug fix recently made to the Intel RDMA driver (irdma) that has made to mainline. > > https://github.com/torvalds/linux/commit/bb6d73d9add68ad270888db327514384df… > subject: RDMA/irdma: Prevent zero-length STAG registration > commit-id: bb6d73d9add68ad270888db327514384dfa44958 > > This problem in theory is possible in i40iw as well. i40iw is replaced with irdma upstream since 5.14. > > However, i40iw is still part of LTS 4.14.x, 4.19.x, 5.4.x, and 5.10. Since it is a security fix, I am thinking its reasonable we backport it to i40iw too for these kernels. The patch would need some adjustments and I can do this if required. If you feel it is needed, yes, please do the needed backport and submit it here. thanks, greg k-h

1 year, 2 months

2
1
0 0

backport 790756c7e022 to 4.14 and 4.19?

by Martin Kaiser

Dear all, after upgrading my toolchain to gcc 13.2 and GNU assembler (GNU Binutils) 2.41.0.20230926, compiling a 4.14 kernel fails arch/arm/mm/proc-arm926.S: Assembler messages: arch/arm/mm/proc-arm926.S:477: Error: junk at end of line, first unrecognized character is `#' The problem is that gas 2.41.0.20230926 does no longer support Solaris style section attributes like .section ".start", #alloc, #execinstr Commit 790756c7e022 ("ARM: 8933/1: replace Sun/Solaris style flag on section directive") fixed up the section attributes that used the legacy syntax. It seems that this commit landed in 5.5 and has already been backported to 5.4. Should we backport this commit to 4.19 and 4.14 as well? If so, should I submit patches that apply against the 4.19 and 4.14 trees or do you want to resolve the conflicts when you queue up the patch? Thanks, Martin

1 year, 2 months

2
1
0 0

[PATCH] drm/amd/display: remove redundant check

by José Pekkarinen

This patch addresses the following warning spotted by using coccinelle where the case checked does the same than the else case. drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c:4664:8-10: WARNING: possible condition with no effect (if == else) Fixes: 974ce181 ("drm/amd/display: Add check for PState change in DCN32") Signed-off-by: José Pekkarinen <jose.pekkarinen(a)foxhound.fi> --- .../drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c index ecea008f19d3..d940dfa5ae43 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c @@ -4661,10 +4661,6 @@ void dml32_CalculateMinAndMaxPrefetchMode( } else if (AllowForPStateChangeOrStutterInVBlankFinal == dm_prefetch_support_uclk_fclk_and_stutter) { *MinPrefetchMode = 0; *MaxPrefetchMode = 0; - } else if (AllowForPStateChangeOrStutterInVBlankFinal == - dm_prefetch_support_uclk_fclk_and_stutter_if_possible) { - *MinPrefetchMode = 0; - *MaxPrefetchMode = 3; } else { *MinPrefetchMode = 0; *MaxPrefetchMode = 3; -- 2.39.2

1 year, 2 months

2
1
0 0

[PATCH] sbsa_gwdt: Calculate timeout with 64-bit math

by Darren Hart

Commit abd3ac7902fb ("watchdog: sbsa: Support architecture version 1") introduced new timer math for watchdog revision 1 with the 48 bit offset register. The gwdt->clk and timeout are u32, but the argument being calculated is u64. Without a cast, the compiler performs u32 operations, truncating intermediate steps, resulting in incorrect values. A watchdog revision 1 implementation with a gwdt->clk of 1GHz and a timeout of 600s writes 3647256576 to the one shot watchdog instead of 300000000000, resulting in the watchdog firing in 3.6s instead of 600s. Force u64 math by casting the first argument (gwdt->clk) as a u64. Make the order of operations explicit with parenthesis. Fixes: abd3ac7902fb ("watchdog: sbsa: Support architecture version 1") Reported-by: Vanshidhar Konda <vanshikonda(a)os.amperecomputing.com> Signed-off-by: Darren Hart <darren(a)os.amperecomputing.com> Cc: Wim Van Sebroeck <wim(a)linux-watchdog.org> Cc: Guenter Roeck <linux(a)roeck-us.net> Cc: linux-watchdog(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: <stable(a)vger.kernel.org> # 5.14.x --- drivers/watchdog/sbsa_gwdt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c index fd3cfdda4949..76527324b63c 100644 --- a/drivers/watchdog/sbsa_gwdt.c +++ b/drivers/watchdog/sbsa_gwdt.c @@ -153,14 +153,14 @@ static int sbsa_gwdt_set_timeout(struct watchdog_device *wdd, timeout = clamp_t(unsigned int, timeout, 1, wdd->max_hw_heartbeat_ms / 1000); if (action) - sbsa_gwdt_reg_write(gwdt->clk * timeout, gwdt); + sbsa_gwdt_reg_write((u64)gwdt->clk * timeout, gwdt); else /* * In the single stage mode, The first signal (WS0) is ignored, * the timeout is (WOR * 2), so the WOR should be configured * to half value of timeout. */ - sbsa_gwdt_reg_write(gwdt->clk / 2 * timeout, gwdt); + sbsa_gwdt_reg_write(((u64)gwdt->clk / 2) * timeout, gwdt); return 0; } -- 2.41.0

1 year, 2 months

3
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2023