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: libav-sta...@libav.org
>>> ---
>>> 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).
lu
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
