On Tue, 17 Sep 2013, Luca Barbato wrote:
On 17/09/13 11:34, Martin Storsjö wrote:
On Mon, 16 Sep 2013, Luca Barbato wrote:
On 16/09/13 21:06, Martin Storsjö wrote:
Since the number of channels is multiplied by 36 and assigned to
to a uint16_t, make sure this calculation didn't overflow. (In
certain cases the calculation could overflow leaving the
truncated block_align at 0, leading to divisions by zero later.)
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: [email protected]
---
libavformat/xmv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/xmv.c b/libavformat/xmv.c
index bc7c3c9..dd8a02d 100644
--- a/libavformat/xmv.c
+++ b/libavformat/xmv.c
@@ -224,7 +224,8 @@ static int xmv_read_header(AVFormatContext *s)
av_log(s, AV_LOG_WARNING, "Unsupported 5.1 ADPCM audio
stream "
"(0x%04X)\n", track->flags);
- if (!track->channels || !track->sample_rate) {
+ if (!track->channels || !track->sample_rate ||
+ track->channels >= UINT16_MAX/36) {
Diego will complain about spaces, I would complain about magic numbers,
the idea is sound.
Spaces added locally, what would you suggest doing about the magic numbers?
We have XMV_MIN_HEADER_SIZE already even if I'm not really sure it is
the same thing (didn't look at the code properly yet).
It's not directly related (and if it is, it's only a coincidence anyway).
It needs to match whatever constant is used in the "block_align =
36*channels" multiplication.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
