A  performance optimization for simple and common cases entails that decode_mcu() calls decode_mcu_fast() to decode a single MCU. A greater speed of the latter function is attributed to the fact that it makes some assumptions that the slower decoding function is not allowed to make. One of these assumptions is that enough data is available in the input buffer, so decode_mcu_fast() does not perform bounds’ checks when reading from the input buffer (via GET_BYTE). Instead, decode_mcu() is responsible for ensuring that the input buffer is big enough for the worst case scenario.

However, the problem is that the estimate does not actually cover the worst case possibility. In specifics, the decode_mcu() assumes a maximum of 128 bytes per block while, actually, blocks with around 438 bytes in length can be crafted. (Note that these 438 bytes are not a proper worst-case estimate but rather just the length the PoC generates.)

External references:

https://wiki.mozilla.org/images/7/77/Libjpeg-turbo-report.pdf

Upstream fix:

https://github.com/libjpeg-turbo/libjpeg-turbo/commit/0463f7c9aad060fcd56e98d025ce16185279e2bc