Andreas Rheinhardt: > Michael Niedermayer: >> Fixes: out of array read >> Fixes: >> 32968/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSP2_fuzzer-5315296027082752 >> >> Found-by: continuous fuzzing process >> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> >> --- >> libavcodec/msp2dec.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/libavcodec/msp2dec.c b/libavcodec/msp2dec.c >> index cc548d218a..87057fb5e2 100644 >> --- a/libavcodec/msp2dec.c >> +++ b/libavcodec/msp2dec.c >> @@ -68,9 +68,10 @@ static int msp2_decode_frame(AVCodecContext *avctx, >> >> bytestream2_init(&gb, buf, pkt_size); >> x = 0; >> - while (bytestream2_get_bytes_left(&gb) && x < width) { >> + while (bytestream2_get_bytes_left(&gb) > 0 && x < width) { > > This decoder uses the checked bytestream2 API, so != 0 and > 0 should be > equivalent for bytestream2_get_bytes_left(&gb). > >> int size = bytestream2_get_byte(&gb); >> if (size) { >> + size = FFMIN(size, bytestream2_get_bytes_left(&gb)); >> memcpy(p->data[0] + y * p->linesize[0] + x, gb.buffer, >> FFMIN(size, width - x)); > > width can include seven bytes of the packet's padding, but it stays > within the padding, so I wonder where the out of array read comes from. > The only fishy thing in this decoder I see is that 2 * avctx->height > might overflow. >
Correction: width has no relationship with the packet's size at all; the width - x in the above FFMIN only ensures that it writes at most seven bytes into the frame's padding (is the frame actually guaranteed to be padded?). Btw: I don't see any advantage of writing in the frame's padding. - 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-requ...@ffmpeg.org with subject "unsubscribe".
