Re: [FFmpeg-devel] [PATCH 2/7] 4xm: prevent overflow during block alignment calculation
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
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
> 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
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