Luca Barbato <[email protected]> writes: > On 24/11/11 14:37, Måns Rullgård wrote: >> Why would this function be called with negative lengths? > > it is used in > > libavcodec/cscd.c: if (av_lzo1x_decode(c->decomp_buf, > &outlen, &buf[2], &inlen)) > libavcodec/nuv.c: if (av_lzo1x_decode(c->decomp_buf, &outlen, > buf, &inlen)) > libavformat/matroskadec.c: result = > av_lzo1x_decode(pkt_data, &olen, data, &isize); > > Shall we guess which of those feeds it something strange?
If either those has a buffer it believes to have negative size, it is horribly broken. In cscd.c the output size is simply width*height*pixel_size, which should (can?) never be negative. In the matroska demuxer, there is at least one case where the input size could be negative if parsing a corrupt/malicious file. This can happen if a block uses "EBML lacing", which codes the size of each packet as a signed difference to the size of the previous one. The parsing of these sizes does not check for overflow (matroskadec.c:1762). Does someone have a file that triggers this condition? -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
