From: Zhao Zhili <quinkblack-at-foxmail.com@ffmpeg.org> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH v3] checkasm/h264dsp: Fix stack overflow in check_idct_dequant Date: Mon, 16 Jun 2025 18:21:19 +0800 Message-ID: <tencent_AD356781BE34513E5B56019C64E0745AB409@qq.com> (raw) In-Reply-To: <GV1P250MB073750F54C8946239F065E458F70A@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM> > On Jun 16, 2025, at 17:46, Andreas Rheinhardt <andreas.rheinhardt@outlook.com> wrote: > > Zhao Zhili: >> From: Zhao Zhili <zhilizhao@tencent.com> >> >> --- >> tests/checkasm/h264dsp.c | 20 +++++++++++++++----- >> 1 file changed, 15 insertions(+), 5 deletions(-) >> >> diff --git a/tests/checkasm/h264dsp.c b/tests/checkasm/h264dsp.c >> index f5f9650224..a0f8fd858a 100644 >> --- a/tests/checkasm/h264dsp.c >> +++ b/tests/checkasm/h264dsp.c >> @@ -328,25 +328,35 @@ static void check_idct_multiple(void) >> static void check_idct_dequant(void) >> { >> static const int depths[5] = { 8, 9, 10, 12, 14 }; >> - LOCAL_ALIGNED_16(int16_t, src, [16]); >> - /* Ensure dst buffers are large enough to hold dctcoefs of all bit-depths. */ >> + /* Ensure buffers are large enough to hold dctcoefs of all bit-depths. */ >> + LOCAL_ALIGNED_16(uint8_t, src_buf, [16 * sizeof(int32_t)]); >> LOCAL_ALIGNED_16(uint8_t, dst0, [16 * 16 * sizeof(int32_t)]); >> LOCAL_ALIGNED_16(uint8_t, dst1, [16 * 16 * sizeof(int32_t)]); >> + int16_t *src = (int16_t *)src_buf; >> int16_t *dst_ref = (int16_t *)dst0; >> int16_t *dst_new = (int16_t *)dst1; >> H264DSPContext h; >> int bit_depth, i, qmul; >> declare_func_emms(AV_CPU_FLAG_MMX | AV_CPU_FLAG_SSE2, void, int16_t *output, int16_t *input, int qmul); >> >> - for (int j = 0; j < 16; j++) >> - src[j] = (rnd() % 512) - 256; >> - >> qmul = rnd() % 4096; >> >> for (i = 0; i < FF_ARRAY_ELEMS(depths); i++) { >> bit_depth = depths[i]; >> ff_h264dsp_init(&h, bit_depth, 1); >> >> + if (bit_depth == 8) { >> + for (size_t j = 0; j < 16; j++) { >> + int16_t r = (rnd() % 512) - 256; >> + AV_WN16A(&src_buf[j << 1], r); >> + } >> + } else { >> + for (size_t j = 0; j < 16; j++) { >> + int32_t r = (rnd() % (1 << (bit_depth + 1))) - (1 << bit_depth); >> + AV_WN32A(&src_buf[j << 2], r); >> + } >> + } >> + >> memset(dst0, 0, 16 * 16 * SIZEOF_COEF); >> memset(dst1, 0, 16 * 16 * SIZEOF_COEF); >> > > This still has an effective-type violation: src_buf is of type uint8_t, > yet the ff_h264_luma_dc_dequant_idct functions will read it as > int16_t/int32_t. It also still has the downside that buffer overflows > for the 8bit case can go undetected. A bunch of template has cast like pixel *dst = (pixel *)_dst; const pixel *src = (const pixel *)_src; then read and write as int16_t. And a bunch of checkasm use uint8_t[] array on stack as src and dst, which leading to UB. This patch isn’t specific. And this patch add zero UB (it’s there before the patch, both src and dst are accessed as int32_t/int16_t while they are int16_t and uint8_t). > > - Andreas > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2025-06-16 10:22 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-06-16 9:40 Zhao Zhili 2025-06-16 9:46 ` Andreas Rheinhardt 2025-06-16 10:21 ` Zhao Zhili [this message] 2025-06-16 11:03 ` Andreas Rheinhardt 2025-06-16 11:49 ` Zhao Zhili 2025-06-16 18:29 ` Andreas Rheinhardt 2025-06-17 2:01 ` Zhao Zhili
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=tencent_AD356781BE34513E5B56019C64E0745AB409@qq.com \ --to=quinkblack-at-foxmail.com@ffmpeg.org \ --cc=ffmpeg-devel@ffmpeg.org \ /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
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git