On Tue, 17 Sep 2013, Vitor Sessak wrote:
On Mon, Sep 16, 2013 at 9:06 PM, Martin Storsjö <[email protected]> wrote:
n_div*2 must be less than 1024 (in read_cb_data in twinvqdec.c).
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: [email protected]
---
libavcodec/twinvq.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavcodec/twinvq.c b/libavcodec/twinvq.c
index 24f5747..29fa754 100644
--- a/libavcodec/twinvq.c
+++ b/libavcodec/twinvq.c
@@ -663,7 +663,7 @@ static av_cold void construct_perm_table(TwinVQContext
*tctx,
size * block_size);
}
-static av_cold void init_bitstream_params(TwinVQContext *tctx)
+static av_cold int init_bitstream_params(TwinVQContext *tctx)
{
const TwinVQModeTab *mtab = tctx->mtab;
int n_ch = tctx->avctx->channels;
@@ -712,6 +712,8 @@ static av_cold void
init_bitstream_params(TwinVQContext *tctx)
}
tctx->n_div[i] = (bit_size + 13) / 14;
+ if (tctx->n_div[i] > 512)
+ return AVERROR_INVALIDDATA;
rounded_up = (bit_size + tctx->n_div[i] - 1) /
tctx->n_div[i];
@@ -736,6 +738,7 @@ static av_cold void
init_bitstream_params(TwinVQContext *tctx)
for (frametype = TWINVQ_FT_SHORT; frametype <= TWINVQ_FT_PPC;
frametype++)
construct_perm_table(tctx, frametype);
+ return 0;
}
av_cold int ff_twinvq_decode_close(AVCodecContext *avctx)
@@ -770,7 +773,10 @@ av_cold int ff_twinvq_decode_init(AVCodecContext
*avctx)
ff_twinvq_decode_close(avctx);
return ret;
}
- init_bitstream_params(tctx);
+ if ((ret = init_bitstream_params(tctx)) < 0) {
+ av_log(avctx, AV_LOG_ERROR, "Invalid bitstream parameters\n");
+ return ret;
+ }
twinvq_memset_float(tctx->bark_hist[0][0], 0.1,
FF_ARRAY_ELEMS(tctx->bark_hist));
I'm fine with the patch, even if I think it should be impossible to trigger
the problem (n_div should depend only on the bitrate and on sample rate,
which we check both against a list of valid values).
Kostya helped me track down the real cause for it - ibps is large enough
to spill over into the isampf area in the "switch ((isampf << 8) + ibps)"
comparison. New patch coming up.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel