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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4