On Sun, 29 Sep 2013, Kostya Shishkov wrote:
On Sun, Sep 29, 2013 at 01:21:07AM +0300, Martin Storsjö wrote:
In lpc_prediction(), we write up to array element 'lpc_order' in
an array allocated to hold 'max_samples_per_frame' elements.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: [email protected]
---
libavcodec/alac.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/alac.c b/libavcodec/alac.c
index 41d1f77..6d1ace3 100644
--- a/libavcodec/alac.c
+++ b/libavcodec/alac.c
@@ -314,6 +314,9 @@ static int decode_element(AVCodecContext *avctx, AVFrame
*frame, int ch_index,
rice_history_mult[ch] = get_bits(&alac->gb, 3);
lpc_order[ch] = get_bits(&alac->gb, 5);
+ if (lpc_order[ch] >= alac->max_samples_per_frame)
+ return AVERROR_INVALIDDATA;
+
/* read the predictor table */
for (i = lpc_order[ch] - 1; i >= 0; i--)
lpc_coefs[ch][i] = get_sbits(&alac->gb, 16);
--
looks a bit strange, I'd expect lpc_order > max_samples_per_frame
In practice it isn't - in some random samples, lpc_order is 5-30 or so,
while max_samples_per_frame is 4096.
The loop that writes out of bounds is this one, in lpc_prediction:
for (i = 1; i <= lpc_order; i++)
buffer_out[i] = sign_extend(buffer_out[i - 1] + error_buffer[i], bps);
OTOH, if lpc_order > max_samples_per_frame is to be expected, we could
perhaps just add an FFMIN() to the loop?
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
