[pkg-mad-maintainers] Bug#870406: Bug#870406: Bug#870406: libmad: CVE-2017-11552

[Kurt Roeckx]

reassign 870406 mpg321
thanks

On Sun, Jan 07, 2018 at 02:43:43PM +0100, Kurt Roeckx wrote:
> I can reproduce this using mpg321, but not using madplay.

Valgrind shows:
==4094== Invalid write of size 8
==4094==    at 0x10EFD0: read_header (mad.c:285)
==4094==    by 0x579EA11: run_sync (decoder.c:392)
==4094==    by 0x579EE16: mad_decoder_run (decoder.c:557)
==4094==    by 0x10C3BA: main (mpg321.c:1092)
==4094==  Address 0x66c3d38 is 0 bytes after a block of size 8 alloc'd
==4094==    at 0x4C2ABEF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4094==    by 0x10CDDD: main (mpg321.c:990)
==4094==
==4094== Invalid write of size 8
==4094==    at 0x10EFDC: read_header (mad.c:287)
==4094==    by 0x579EA11: run_sync (decoder.c:392)
==4094==    by 0x579EE16: mad_decoder_run (decoder.c:557)
==4094==    by 0x10C3BA: main (mpg321.c:1092)
==4094==  Address 0x66c3d90 is 0 bytes after a block of size 16 alloc'd
==4094==    at 0x4C2ABEF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4094==    by 0x10CDED: main (mpg321.c:991)
==4094==

That's this code in mpg321's mad.c:
    /* update cached table of frames & times */
    if (current_frame <= playbuf->num_frames) /* we only allocate enough for our estimate. */
    {
        playbuf->frames[current_frame] = playbuf->frames[current_frame-1] + (header->bitrate / 8 / 1000)
            * mad_timer_count(header->duration, MAD_UNITS_MILLISECONDS);
        playbuf->times[current_frame] = current_time;
    }

And later we crash when libmad tries to free() something it
allocated.

If I change mpg321 to allocate 1 more frame in mpg321.c:990 and 991,
the crash goes away. (Note that this is not a fix at all, it's
just showing that mpg321 is the source of the problem.)

It at least seems that mpg321 lost info about the amount of frames
it allocated somewhere. It might be related to the frames that
failed to decode.


Kurt