From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id A4C1C4F2C9 for ; Mon, 16 Jun 2025 08:19:23 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 331B668DAFA; Mon, 16 Jun 2025 11:19:19 +0300 (EEST) Received: from out203-205-221-221.mail.qq.com (out203-205-221-221.mail.qq.com [203.205.221.221]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id 7022668D30A for ; Mon, 16 Jun 2025 11:19:11 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1750061946; bh=Xc4UQ+CJO1yMOD5LuYDPeUcWnmHDQk2OlVgF7Cyzj6s=; h=From:Subject:Date:References:To:In-Reply-To; b=YgUuAnYWjBHFxeT/H249g5jveFyIQbTQs1sL9gW7z1zX0DFW6gZcH+MHt+79DfyfQ MBpLPECHOZdFRicZAXksV5kNv2l1ZUzZkD+NiHenA9u/SCAEmtIqU15+YWkyOq8C7p CAIKRlPhmjmtt7zaDFySqAcuk/d74Lm1f4Z7tgZQ= Received: from smtpclient.apple ([119.147.10.242]) by newxmesmtplogicsvrszc16-0.qq.com (NewEsmtp) with SMTP id 4C5AB60C; Mon, 16 Jun 2025 16:19:05 +0800 X-QQ-mid: xmsmtpt1750061945t56fyhu50 Message-ID: X-QQ-XMAILINFO: OZZSS56D9fAj98ABIvSQcUqrnbL/9JBOdBTaQq21sMFXd+lYDRHBUOXK/q359k /J06+C+suq4gwjbSnHZX11CtYx1LDIk9s0Wm8I57sulRTeTU/W+c/Vl469ZeE1tQLT7yzL1Wgtnc i4jIitIBCWZgXGQmaLBmP14SegZkIWkqdaRwUUilTLMPP9wvLFa3koNTBFC44WB4FIBCnDfG1NlN H88njZCLdWG2BvN4lhXPZ26D9yuOIAwsy4W2h0c7OwRbFDz0i1QB2Gu3O1iu/TDQmHCERS6Wc02t tlEJyL3qnJqtPKDJrbUJLfBZKxUvsHkiITdM622grns72XZ4Rw2rc72ALJtk+vDvoUjoPpsOgxiD 50lOpMB3cDwiJg7/67cUT3xso+ccvnhDMXHvBkHh6cbP/j7/eVUjXjYzko0RL/5dc/Kdo6kX4uMB JUqc7ebk0A8uGnGaWVfKRlSE5hl+4+LZ+BdB35fZz9QUt2DNhdqj5t4VLwQDT1qPWoUjoZFQyepa 5Z5IcrDvHEMrTIrxa12cSQOr10FJac+kyCEFak6kh909xIt+VxI3iPsd2MqRhyqAKa7S+o52geHq EAW2YQggs7LxVJpXy+HzD9MkKdGH6v6ymuRoZ3w8hQmqqm7FPtD0ncHlqgTZIa2N1V0BoL1HA10m SFE6/nnSCXAhFsYJfB+Km21iCvis0tnqFO2Wl5I13d7GKCmMWE3eAnctj+Abikpe+vCB8f9rNsOy GDqdkh9EdrvjAXTH0bEBwRIG7JIXka/s4J56zKlamNFNg4QeSB7WQkTfh4FOLjpiiPhDcBDHKnoi LDoobL7ytDsuvXotNKvjSMQa9CdEHxCXl4KV34ECKLu6DxQUNfkL5Hul4JzMqWhwSclJEWDMIuOV Fpw+03/RkEfZlxUL22HPqzd6AKJMitxj0kkPa8KdWtAE/lpe23WjLUw+Ec1gTG8+ianO5j92zM3e EQ+N9tZ0phViLIuLA3RW5IF8J6aEfIv8vye1iuesGvt1JdHPuf65dxmEhgC0TX4/0RIQXtYGlB9H Lzub4bSvCGA/CsgtRi X-QQ-XMRINFO: NI4Ajvh11aEj8Xl/2s1/T8w= From: Zhao Zhili Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Date: Mon, 16 Jun 2025 16:18:55 +0800 References: To: FFmpeg development discussions and patches In-Reply-To: X-OQ-MSGID: X-Mailer: Apple Mail (2.3826.500.181.1.5) Subject: Re: [FFmpeg-devel] [PATCH] checkasm/h264dsp: Fix stack overflow in check_idct_dequant X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: > On Jun 16, 2025, at 15:16, Andreas Rheinhardt wrote: > > Zhao Zhili: >> From: Zhao Zhili >> >> --- >> tests/checkasm/h264dsp.c | 14 ++++++++++---- >> 1 file changed, 10 insertions(+), 4 deletions(-) >> >> diff --git a/tests/checkasm/h264dsp.c b/tests/checkasm/h264dsp.c >> index f5f9650224..006532e08b 100644 >> --- a/tests/checkasm/h264dsp.c >> +++ b/tests/checkasm/h264dsp.c >> @@ -328,7 +328,7 @@ 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]); >> + LOCAL_ALIGNED_16(int16_t, src, [16 * 2]); >> /* Ensure dst buffers are large enough to hold dctcoefs of all bit-depths. */ >> LOCAL_ALIGNED_16(uint8_t, dst0, [16 * 16 * sizeof(int32_t)]); >> LOCAL_ALIGNED_16(uint8_t, dst1, [16 * 16 * sizeof(int32_t)]); >> @@ -338,15 +338,21 @@ static void check_idct_dequant(void) >> 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 (int j = 0; j < 16; j++) >> + src[j] = (rnd() % 512) - 256; >> + } else { >> + int32_t *p = (int32_t *)src; >> + for (int j = 0; j < 16; j++) >> + p[j] = (rnd() % (1 << (bit_depth + 1))) - (1 << bit_depth); > > This is an effective type violation and therefore UB. Yes. And the template functions are UB. > Furthermore, > increasing the size of the array has the downside that stack overflows > in the 8 bit codepath may go undetected. So better add a > LOCAL_ALIGNED_16(int32_t, src32, [16]) and use that for the >8 bit tests. I think this is still UB by pass it as argument to h264_luma_dc_dequant_idct, due to the function prototype. I have no idea other than union or separate test case. > >> + } >> + >> memset(dst0, 0, 16 * 16 * SIZEOF_COEF); >> memset(dst1, 0, 16 * 16 * SIZEOF_COEF); >> > > _______________________________________________ > 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".