Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
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".

  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