FLAC seekpoints are coded in unsigned 64-bit ints, but the code
handling them uses signed 64-bit ints. Since users are unlikely
to run into this limit anyway, do not use seekpoints larger than
INT64_MAX
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48112
Commit 3fc5ba4 replaced a seeking error with specific handling.
This handling consisted of lowering the upper seek bound.
However, this handling was both slow and wrong. Because it is slow
it causes fuzzing timeouts. It was wrong in that if there was
another valid frame in the boguss frame being read, it would no
longer be reachable.
This commit replaces the handling with another approach: instead of
lowering the upper bound, the lower bound is raised. With this, the
calculation of pos for the next seek is changed and the seeking code
hopefully ends up somewhere not decoding the bogus frame.
If in decoding the frame at lower bound eof is still reached,
a seek error is thrown. This is reasonable, as lower bound should
be after the end of the last frame (not somewhere halfway a frame)
and if a corrupt frame is encountered, proper seeking cannot be
reasonably expected. It could be argued that it is still possible
to try and lower the upper bound by trying to decode a frame by
moving one byte backward at a time, looking for a frame, but this
will probably cause fuzzer timeouts and as said, proper seeking
in such a stream cannot be reaonably expected.
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48077
Without this patch, the order of the arguments matter, with it
it does not: specific compression settings now always override
the more generic compression levels. This fixes issue
https://github.com/xiph/flac/issues/20
On fuzzing the assertion
'decoder->private_->last_frame.header.number_type ==
FLAC__FRAME_NUMBER_TYPE_SAMPLE_NUMBER' failed. This was because it
was possible to get there without having decoded a valid frame yet.
The checks are rearranged such that the code past this assertion is
only reached after it is made sure a valid frame has been decoded.
When a call to read_callback failed in bitreader_read_from_client_
it left the bitreader buffer in a state where the last word was swapped
for endianness. While this wasn't ever a problem, recently code was
merged that rewound the bitreader in case a bogus frame was found.
If this happened, the bitreader buffer would be used in the state
where the last word in the buffer was still swapped. This commit
restores the last word of the buffer in case the call to the
read callback fails
Decoding for 32-bit files is added, including the ability to decode
a 33-bit side subframe. However, residuals are assumed to be limited
to a 32-bit signed int, the encoder must make sure of this
I think this is from the jenkins era. For a while we tried to
consolidate continuous-integration build descriptions across
services, but the formats are different enough that it's been
easier to use separate, per-service implementations.
In any case, this isn't used any more so there's no reason to
keep it around.
Add a github action to build and verify the traditional distribution
source package with GNU Autotools, also known as `make distcheck`.
This helps catch errors propagating required file list changes.
Co-authored-by: Martijn van Beurden <mvanb1@gmail.com>
fuzzer_decoder was running into timeouts because it triggered the
gap-filling for broken frames with 5*192000 samples and a blocksize
of 1, causing the write callback to be called 960000 times. Doing
this several times in one file caused a single fuzz run to take
> 60 seconds
This commit limits the minimum blocksize to 16 samples, and the
maximum number of frames emitted to 50
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47193
This commit drops all use of assembler and intrinsics from the libFLAC
decoder. This is because they are only for 32-bit x86, hard to debug,
maintain and fuzz properly, and because the decoder has much greater
security risks than the encoder.
Escape coding has been deprecated since FLAC 1.0.4 (24-Sep-2002), but
it is needed for full spec coverage, (as this is a reference
implementation after all) so this should be reenabled at some point.
For now only enable while fuzzing, so we can get some bugs out first.
The loose mid-side option only fully evaluates stereo decorrelation
once every few frames. However, in case of finding left-side or
right-side to be the best option, subsequent frames were coded
mid-side, which could be worse off. To not complicate code too much
(to make it possible to evaluate only left or right and side frame
for example), evaluation of left-side and right-side is completely
disabled when loose mid-side is enabled.
When an unknown picture type was found, the resulting type wouldn't
occur in the enum, which is undefined behaviour. This commit changes
the picture type to 0 (other) when that happens.
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=46964
The mechanism to improve metadata reading added in 0077d3b overrides
a FLAC__STREAM_DECODER_ABORTED with
FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC causing the decoder to
overread a buffer into an uninitialized part. A check is added that
ensures searching for frame sync is only set when the decoder is
still in a valid state
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47525
Adds /arch:avx2 to the avx2-specific source files. This mirrors the
current vcxproj files. While it currently brings no improvements,
it might if CPU-specific optimization is left to the compiler
instead of with hand-optimized code in the future
Also, the exact meaning of options WITH_SSE2 and WITH_AVX is
stated, as the first is compile-time only, and the second also
has runtime detection
Based on some information somewhere on the internet, CMakeLists.txt
sets _FORTIFY_SOURCE=2 when its runtime functions are available and
_FORTIFY_SOURCE=1 when they are not. However, _FORTIFY_SOURCE=1
also requires runtime functions.
libFLAC DLLs were exposing windows_unicode_filename.h functions
because flac and metaflac needed to set flac_internal_set_utf8_
filenames. Files windows_unicode_filename.{c/h} and
win_utf8_io.[c/h] are merged, and all non-utf8 parts are removed.
With this commit, the libFLAC DLL interface is the same as the
libFLAC interface of shared libraries on other platforms
Commit 5df56db introduced four completely rewritten functions with
intrinsics, but it turns out two of them have integers that can
overflow. Because those two functions were barely faster than
what they replaced, fixing these overflows will probably make the
functions slower than what they replaced, so this is reverted.
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47416
