I discovered an division by zero vulnerability in lame, which is caused by mal-constructed input file using American Fuzzy Loop.
I'm pretty sure that is a duplicate of: https://blogs.gentoo.org/ago/2017/06/17/lame-divide-by-zero-in-parse_wave_header-get_audio-c/
CVE ID: CVE-2017-15018
Summary: LAME 3.99.5 has a heap-based buffer over-read when handling a malformed file in k_34_4 in vbrquantize.c.
CVE ID: CVE-2017-15019
Summary: LAME 3.99.5 has a NULL Pointer Dereference in the hip_decode_init function within libmp3lame/mpglib_interface.c via a malformed mpg file, because of an incorrect calloc call.
CVE ID: CVE-2017-8419
Summary: LAME through 3.99.5 relies on the signed integer data type for values in a WAV or AIFF header, which allows remote attackers to cause a denial of service (stack-based buffer overflow or heap-based buffer overflow) or possibly have unspecified other impact via a crafted file, as demonstrated by mishandling of num_channels.
CVE ID: CVE-2017-11720
Summary: There is a division-by-zero vulnerability in LAME 3.99.5, caused by a malformed input file.
Package is a B and the DoS rates a 3. No PoC for ACE/RCE due to "unspecified impacts" wording in CVE.
GLSA Vote: No.
Cleanup will be handled in bug #634598