In the call to decode_residue:
decode_residue(f, residue_buffers, ch, n2, r, do_not_decode);
The channel count is previously intialized as zero and incremented
based on a for-loop (f->channels) plus a conditional,
if (map->chan[j].mux == i). If this doesn't happen then 'ch'
remains zero.
Once inside decode_residue(..), the code has three branches based
on channel count: stereo (ch == 2), mono (ch == 1), and then the
exception if it's neither of those (simple 'else'). It's in here
where a zero-valued 'ch' can be used as the denominator in these
calculations:
int c_inter = z % ch
p_inter = z/ch;
Obviously this 'else' branch is meant for channel counts greater
than two an not for zero channels; so this change simply makes
that branch only valid if (ch > 2).
CVE-2019-13217: heap buffer overflow in start_decoder()
CVE-2019-13218: stack buffer overflow in compute_codewords()
CVE-2019-13219: uninitialized memory in vorbis_decode_packet_rest()
CVE-2019-13220: out-of-range read in draw_line()
CVE-2019-13221: issue with large 1D codebooks in lookup1_values()
CVE-2019-13222: unchecked NULL returned by get_window()
CVE-2019-13223: division by zero in predict_point()
When calling stbtt_PackFontRanges, multiple missing glyphs in the range
of codepoints will create multiple copies of the font's missing glyph to
be added to the pixel buffer. Instead, the first codepoint that maps to the missing glyph will add it to the pixel buffer, and all subsequent glyphs will simply copy the stbtt_packedchar data to reference the same region of the buffer.
This does NOT prevent duplication in multiple calls to stbtt_PackFontRange(s) - that would require modifying the packing context, which could be nice but is a bit more intrusive.
