mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-11-14 01:59:34 +01:00
Henrik Rydgård
1830945ca7
demux()'s "not enough data, rewind and try again next time" logic unconditionally subtracted 4 (or 6) from m_index, assuming that many bytes were consumed scanning for a start code. But the inner scan can also exit via reaching the end of the buffer without finding a start code at all, having consumed fewer bytes than that - when the buffer holds under 4 bytes total, m_index goes negative, and the subsequent memmove(m_buf, m_buf + m_index, size) then reads before the start of m_buf. Clamp the rewind to 0. read8()/skip() also had no bounds check against m_len (the actual buffer allocation) at all - readPesHeader()'s header-length fields are only cross-checked against the outer PES packet length, not against how much data is actually available, so a crafted stream claiming a long header could walk m_index past the buffer. Bound both against m_len directly, at the lowest-level primitives so every caller is covered.