On Mon, Jun 27, 2022 at 07:57:06AM +0200, Andreas Rheinhardt wrote: > Michael Niedermayer: > > Fixes: out of array access > > Fixes: 47936/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5745039940124672 > > > > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/qpeldsp.c | 12 ++++++------ > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/libavcodec/qpeldsp.c b/libavcodec/qpeldsp.c > > index 2b9146ceb1..5f937f9d9e 100644 > > --- a/libavcodec/qpeldsp.c > > +++ b/libavcodec/qpeldsp.c > > @@ -199,7 +199,7 @@ static void OPNAME ## qpel8_mc01_c(uint8_t *dst, const uint8_t *src, \ > > uint8_t full[16 * 9]; \ > > uint8_t half[64]; \ > > \ > > - copy_block9(full, src, 16, stride, 9); \ > > + copy_block8(full, src, 16, stride, 9); \ > > put ## RND ## mpeg4_qpel8_v_lowpass(half, full, 8, 16); \ > > OPNAME ## pixels8_l2_8(dst, full, half, stride, 16, 8, 8); \ > > } \ > > @@ -209,7 +209,7 @@ static void OPNAME ## qpel8_mc02_c(uint8_t *dst, const uint8_t *src, \ > > { \ > > uint8_t full[16 * 9]; \ > > \ > > - copy_block9(full, src, 16, stride, 9); \ > > + copy_block8(full, src, 16, stride, 9); \ > > OPNAME ## mpeg4_qpel8_v_lowpass(dst, full, stride, 16); \ > > } \ > > \ > > @@ -219,7 +219,7 @@ static void OPNAME ## qpel8_mc03_c(uint8_t *dst, const uint8_t *src, \ > > uint8_t full[16 * 9]; \ > > uint8_t half[64]; \ > > \ > > - copy_block9(full, src, 16, stride, 9); \ > > + copy_block8(full, src, 16, stride, 9); \ > > put ## RND ## mpeg4_qpel8_v_lowpass(half, full, 8, 16); \ > > OPNAME ## pixels8_l2_8(dst, full + 16, half, stride, 16, 8, 8); \ > > } \ > > @@ -459,7 +459,7 @@ static void OPNAME ## qpel16_mc01_c(uint8_t *dst, const uint8_t *src, \ > > uint8_t full[24 * 17]; \ > > uint8_t half[256]; \ > > \ > > - copy_block17(full, src, 24, stride, 17); \ > > + copy_block16(full, src, 24, stride, 17); \ > > put ## RND ## mpeg4_qpel16_v_lowpass(half, full, 16, 24); \ > > OPNAME ## pixels16_l2_8(dst, full, half, stride, 24, 16, 16); \ > > } \ > > @@ -469,7 +469,7 @@ static void OPNAME ## qpel16_mc02_c(uint8_t *dst, const uint8_t *src, \ > > { \ > > uint8_t full[24 * 17]; \ > > \ > > - copy_block17(full, src, 24, stride, 17); \ > > + copy_block16(full, src, 24, stride, 17); \ > > OPNAME ## mpeg4_qpel16_v_lowpass(dst, full, stride, 24); \ > > } \ > > \ > > @@ -479,7 +479,7 @@ static void OPNAME ## qpel16_mc03_c(uint8_t *dst, const uint8_t *src, \ > > uint8_t full[24 * 17]; \ > > uint8_t half[256]; \ > > \ > > - copy_block17(full, src, 24, stride, 17); \ > > + copy_block16(full, src, 24, stride, 17); \ > > put ## RND ## mpeg4_qpel16_v_lowpass(half, full, 16, 24); \ > > OPNAME ## pixels16_l2_8(dst, full + 24, half, stride, 24, 16, 16); \ > > } \ > > Are the arch-specific dsp functions affected by this, too? the fuzzer sample does not cause a anomaly in the x86 functions > Do you happen to know why copy_block9/17 has been used in this code? probably because there was asm anyway so it was unused code or maybe it was oversight or some sort of code sharing/code cache use reduction but these hypothesis dont fit entirely. so i dont really know/rememeber > (After all, using copy_block8/16 should result in a slight speedup, so I > using copy_block9/17 must have been intentional.) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Homeopathy is like voting while filling the ballot out with transparent ink. Sometimes the outcome one wanted occurs. Rarely its worse than filling out a ballot properly.