Make sure we notice when the lace_size[n] is a negative value.
CC: [email protected]
---
It is solving some issues and avoids having more checks in an inner loop,
I'm not fully convince I didn't overlook some corner cases.
EBML lace sizes are encoded as difference, so a corrupted value would lead
to negative lace, we store the sizes as uint32_t so in that case it
would become an value surely bigger than expected and using an uint64_t for
total should be enough to catch the problem in a single check.
Currently it doesn't work because total is uint32_t, making the value overflow
once in lace_size[n] and then overflow again in total.
libavformat/matroskadec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 2ec669f..67a3308 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1820,7 +1820,7 @@ static int matroska_parse_laces(MatroskaDemuxContext
*matroska, uint8_t **buf,
case 0x3: /* EBML lacing */ {
uint64_t num;
- uint32_t total;
+ uint64_t total;
n = matroska_ebmlnum_uint(matroska, data, size, &num);
if (n < 0) {
av_log(matroska->ctx, AV_LOG_INFO,
--
1.8.1.5
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
