[Ffmpeg-devel] [PATCH] flac crash when pred_order too big

Justin Ruggles justinruggles
Wed Jan 17 08:13:18 CET 2007


Michael Niedermayer wrote:
> Hi
> 
> On Tue, Jan 16, 2007 at 04:00:53PM +0100, Reimar Doeffinger wrote:
> 
>>Hello,
>>attached patch fixes a crash when pred_order > s->blocksize >>
>>rice_order, as exposed by http://sam.zoy.org/zzuf/lol-mplayer.flac
>>Since I do not know the spec i have no idea if this patch is the correct
>>way to fix it though (though it is very simple and looks like it could
>>make sense).
> 
> 
> iam more in favor of print error + return -1; 
> if pred_order > s->blocksize >> rice_order
> 
> and spec says:
> Encoded residual. The number of samples (n) in the partition is determined as follows:
> 
> * if the partition order is zero, n = frame's blocksize - predictor order 
> * else if this is not the first partition of the subframe, n = (frame's blocksize / (2^partition order)) 
> * else n = (frame's blocksize / (2^partition order)) - predictor order

I want to chime in here and say that this part of the spec can get
really tricky.  Your fix would pretty much take care of overruns here,
but errors in encoding or data corruption could also lead, in some
cases, to not reading enough residuals.  The blocksize is not inherently
evenly divisible by 2^partition order, but the encoder is supposed to
choose a partition order which will make that happen (that part of it is
not in the spec).  If this does not happen or the data gets corrupted,
too few residuals could be decoded and it would throw off the alignment.
 The result would likely be that it would crap out at the next frame
boundary or sooner, but this is not a guarantee.  The issue is probably
not a security risk, but it's still a critical thing for a lossless codec.

Maybe the solution could be something as simple as verifying that the
number of decoded residuals matches the block size.  I'll take a closer
look at the code tomorrow and submit a patch. :)

-Justin




More information about the ffmpeg-devel mailing list