Latest mpg321 0.3.2, in scan() in mad.c calculate the number of frames
using bit rate.
If mp3 whose bit rate equal 0 is taken, sampling time become
INF value due to floating point division by 0.
As a result, the frame number become a very large (1<<63), leading out
of bounds write, memory corruption at mad.c:285.
282 / update cached table of frames & times /
283 if (current_frame <= playbuf->num_frames) / we only allocate enough for our estimate. /
284 {
285 playbuf->frames[current_frame] = playbuf->frames[current_frame-1] + (header->bitrate / 8 / 1000)
286 * mad_timer_count(header->duration, MAD_UNITS_MILLISECONDS);
287 playbuf->times[current_frame] = current_time;
Frames buffer have been allocated only 8-byte at mpg321.c:990 due to Integer Overflow(mpg321.c:990)
985 if ((options.maxframes != -1) && (options.maxframes <= playbuf.num_frames))
986 {
987 playbuf.max_frames = options.maxframes;
988 }
989
990 playbuf.frames = malloc((playbuf.num_frames + 1) * sizeof(void*));
991 playbuf.times = malloc((playbuf.num_frames + 1) * sizeof(mad_timer_t));
The value of playbuf.num_frames may depend on platform because it's calculated from INF value. (undefined behavior)
In my environment (Ubuntu 18.04, gcc 7), it becomes 0x8000000000000000 and
calculate (0x8000000000000000 + 1) * 8 = 0x8 (INTEGER OVERFLOW).
This problem also had been reported to Ubuntu security team and got a response, that they'll check the detail.
Could you fix that?
Also see.
https://seclists.org/oss-sec/2018/q4/206
https://seclists.org/oss-sec/2018/q4/211
The patch as it was added in Debian upload versioned as 0.3.2-2 should fix this issue.