The JPEG spec allows component IDs to be chosen arbitrarily from the
interval [0, 255]. Storing components in a vector corrupts the decoder
when component IDs are not in the range 0-3. Normally, encoders don't
use IDs outside of that range because JPEG doesn't support more than
4 channels. But since there is a chance that a spec compliant JPEG
would have component IDs outside of [0-3], we should consider replacing
the vector, which enforces serial component access based on component
IDs, with a HashMap<u8, ComponentSpec>.
This doesn't fix all the issues found by the fuzzer, but it fixes
many of them. When running this
Meta/Lagom/Fuzzers/FuzzJPGLoader -jobs=24 -workers=24 \
../Base/res/html/misc/jpgsuite_files/
for 10 minutes on my machine, the fuzzer foudn 2 crashers, but after
this change it finds just ... 2. But with different stacks!
This just fixes ASSERT()s, so it's not security critical, but
ASSERT()s still crash the programs decoding JPGs, and crashing
less is nice even if it's not a security concern.
DC and AC table IDs read in the scan header segment weren't validated
against the IDs of Huffman tables read in the DHT segment. This caused
an OOB read when a Huffman table was accessed using the ID read in the
scan header segment. Furthermore, the decoder now replaces the old DC
or AC table if a redefinition has been found prior to the scan header.
Fixes#3439.
The SI prefixes "k", "M", "G" mean "10^3", "10^6", "10^9".
The IEC prefixes "Ki", "Mi", "Gi" mean "2^10", "2^20", "2^30".
Let's use the correct name, at least in code.
Only changes the name of the constants, no other behavior change.
This function did a const_cast internally which made the call side look
"safe". This method is removed completely and call sites are replaced
with ByteBuffer::wrap(const_cast<void*>(data), size) which makes the
behaviour obvious.
This patch adds support for JPEG decoding. The JPEG decoder is capable
of handling standard 2x1 horizontal, 2x1 vertical and quartered chroma
subsampling. The implemented Inverse DCT performs with a decent speed.
As of interchange formats, since we tend to ignore the metadata in APPn
markers, the decoder can handle any format compatible with JFIF, which
includes EXIFs and sometimes WebMs too. The decoder does not support
progressive JPEGs yet.
