Re: [FFmpeg-devel] [PATCH 2/7] 4xm: prevent overflow during block alignment calculation

2016-12-16 Thread Michael Niedermayer
On Fri, Dec 16, 2016 at 03:32:42AM +0100, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/4xm.c | 1 +
>  1 file changed, 1 insertion(+)

should be ok

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 2/7] 4xm: prevent overflow during block alignment calculation

2016-12-15 Thread Andreas Cadhalpun
On 16.12.2016 03:33, Rodger Combs wrote:
> 
>> On Dec 15, 2016, at 20:32, Andreas Cadhalpun 
>>  wrote:
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>> libavformat/4xm.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/4xm.c b/libavformat/4xm.c
>> index 2758b69..9332f78 100644
>> --- a/libavformat/4xm.c
>> +++ b/libavformat/4xm.c
>> @@ -187,6 +187,7 @@ static int parse_strk(AVFormatContext *s,
>> st->codecpar->bit_rate  = (int64_t)st->codecpar->channels *
>>   st->codecpar->sample_rate *
>>   
>> st->codecpar->bits_per_coded_sample;
>> +FF_BAIL_ON_OVERFLOW(s, st->codecpar->channels && 
>> st->codecpar->bits_per_coded_sample > INT_MAX / st->codecpar->channels)
> 
> Shouldn't this go before the actual (potentially-overflowing) calculation is 
> done?

It is.

>> st->codecpar->block_align   = st->codecpar->channels *
>>   
>> st->codecpar->bits_per_coded_sample;

This here is the problem.

Best regards,
Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 2/7] 4xm: prevent overflow during block alignment calculation

2016-12-15 Thread Rodger Combs

> On Dec 15, 2016, at 20:32, Andreas Cadhalpun 
>  wrote:
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
> libavformat/4xm.c | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/4xm.c b/libavformat/4xm.c
> index 2758b69..9332f78 100644
> --- a/libavformat/4xm.c
> +++ b/libavformat/4xm.c
> @@ -187,6 +187,7 @@ static int parse_strk(AVFormatContext *s,
> st->codecpar->bit_rate  = (int64_t)st->codecpar->channels *
>   st->codecpar->sample_rate *
>   st->codecpar->bits_per_coded_sample;
> +FF_BAIL_ON_OVERFLOW(s, st->codecpar->channels && 
> st->codecpar->bits_per_coded_sample > INT_MAX / st->codecpar->channels)

Shouldn't this go before the actual (potentially-overflowing) calculation is 
done?

> st->codecpar->block_align   = st->codecpar->channels *
>   st->codecpar->bits_per_coded_sample;
> 
> -- 
> 2.10.2
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 2/7] 4xm: prevent overflow during block alignment calculation

2016-12-15 Thread Andreas Cadhalpun
Signed-off-by: Andreas Cadhalpun 
---
 libavformat/4xm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/4xm.c b/libavformat/4xm.c
index 2758b69..9332f78 100644
--- a/libavformat/4xm.c
+++ b/libavformat/4xm.c
@@ -187,6 +187,7 @@ static int parse_strk(AVFormatContext *s,
 st->codecpar->bit_rate  = (int64_t)st->codecpar->channels *
   st->codecpar->sample_rate *
   st->codecpar->bits_per_coded_sample;
+FF_BAIL_ON_OVERFLOW(s, st->codecpar->channels && 
st->codecpar->bits_per_coded_sample > INT_MAX / st->codecpar->channels)
 st->codecpar->block_align   = st->codecpar->channels *
   st->codecpar->bits_per_coded_sample;
 
-- 
2.10.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel