On 17/09/13 11:43, Martin Storsjö wrote: > On Tue, 17 Sep 2013, Luca Barbato wrote: > >> On 17/09/13 11:34, Martin Storsjö wrote: >>> On Mon, 16 Sep 2013, Luca Barbato wrote: >>> >>>> On 16/09/13 21:06, Martin Storsjö wrote: >>>>> Since the number of channels is multiplied by 36 and assigned to >>>>> to a uint16_t, make sure this calculation didn't overflow. (In >>>>> certain cases the calculation could overflow leaving the >>>>> truncated block_align at 0, leading to divisions by zero later.) >>>>> >>>>> Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind >>>>> CC: [email protected] >>>>> --- >>>>> libavformat/xmv.c | 3 ++- >>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/libavformat/xmv.c b/libavformat/xmv.c >>>>> index bc7c3c9..dd8a02d 100644 >>>>> --- a/libavformat/xmv.c >>>>> +++ b/libavformat/xmv.c >>>>> @@ -224,7 +224,8 @@ static int xmv_read_header(AVFormatContext *s) >>>>> av_log(s, AV_LOG_WARNING, "Unsupported 5.1 ADPCM audio >>>>> stream " >>>>> "(0x%04X)\n", track->flags); >>>>> >>>>> - if (!track->channels || !track->sample_rate) { >>>>> + if (!track->channels || !track->sample_rate || >>>>> + track->channels >= UINT16_MAX/36) { >>>> >>>> Diego will complain about spaces, I would complain about magic numbers, >>>> the idea is sound. >>> >>> Spaces added locally, what would you suggest doing about the magic >>> numbers? >> >> >> We have XMV_MIN_HEADER_SIZE already even if I'm not really sure it is >> the same thing (didn't look at the code properly yet). > > It's not directly related (and if it is, it's only a coincidence > anyway). It needs to match whatever constant is used in the "block_align > = 36*channels" multiplication. >
XMV_BLOCK_ALIGN_SIZE then. > // Martin > _______________________________________________ > libav-devel mailing list > [email protected] > https://lists.libav.org/mailman/listinfo/libav-devel _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
