The overhead of calling clock() when encoding/decoding very small
frames turned out to be very large, for framesize 16 these syscalls
took over half the execution time. This commit only calls clock()
when at least 10.000 samples have been encoded or 25.000 samples
have been decoded since the last call to clock()
During application of replaygain, bps is checked to be > 0. This
should never happen in a valid file. This check is specific for
replaygain application instead of more generic (at streaminfo)
because we still want to be able to recover files in which
streaminfo is invalid or missing.
Previously, too large chunks of foreign metadata (> 16MiB) were
signalled by libFLAC, throwing an error upon adding the metadata,
so flac gave a rather vague error back to the user. This commit
adds detection to the foreign metadata handling, so the user gets
a much clearer error.
Credit: Oss-Fuzz
Issue: N/A
This fixes https://github.com/xiph/flac/issues/580
The problem was that after encountering a problem in a first
subframe, the state was changed from READ_FRAME to
SEARCH_FOR_FRAME_SYNC, which meant a problem in the second
subframe was interpreted as a read error instead of invalid data.
With this patch, processing of subframes is stopped after setting
SEARCH_FOR_FRAME_SYNC
After seeking, a partial frame is passed to the write callback.
The FLAC__Frame passed there only has its blocksize and sample
number changed to accomodate. This results in several 'rules'
being violated. For example, the predictor order can be larger
than the blocksize. This caused integer underflow in the analysis
output of the flac command line program, causing heap overflow.
Also, the output analysis data is junk, because the residual and
rice parameters are not changed accordingly, as this would
violate other things that are otherwise given, like the number
of rice partitions being a power of 2.
To remedy this, a FLAC__Frame is now output stating that all
subframes are of the verbatim type, which has no restrictions
like fixed and lpc subframes have.
A better remedy will have to wait to the next API change, to
introduce a few new subframe types for this case and the case
of conveying an unreadable frame.
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=58481
The code parsing cuepoints of the form MM:SS.SS, which is only
allowed for non-CDDA, had a bug where the first S of the above
template was skipped. That meant that 00:12.34 was parsed as
00:02.34. This is not covered in the test suite, but fuzzing
stumbled on it as 00: as input made the parser skip the string-
terminating nul.
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=57320
When building the tool fuzzers, I excluded some code reading from
stdin because it caused blocking of the fuzzer (i.e. timeouts).
However, the fuzzer now handles stdin, so these exclusions can be
removed
It seems the fuzzer tries to add a picture file, for which the
file was available during fuzzing but not during reproducing. This
fix seems the most logical place it was failing.
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=58371
'first' was handed to flac__encode_file on the first file of a
set, to let that function know replaygain needs to be initialized.
However, when processing of the first file fails, the second file
uses replaygain uninitialized.
The last seen framesync in the bitreader was invalidated when
reading new data in. However, data only leaved the buffer when
more than one word has been fully read. When an invalid frame is
read and reading is aborted within less than a wordlength because
of reaching end-of-stream, the read_from_client had invalidated
the last seen framesync, causing rewinding to the start of the
bitreader. This causes an infinite loop, syncing on the same
pattern every time.
Issue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56395
remains unreproducible to me, and the whole problem doesn't seem
to make any sense. Even downloading the affected build and running
it locally doesn't reproduce the problem.
As this is probably a harmless bug (if it is a bug) that is
triggered by an assert but is handled anyway, I'm hiding the assert
so the handling is fuzzed when the assert is removed, as in
production code.
Currently, when the decoder finds that it is missing some data,
it will fill that up with silence. However, it uses the output
buffer for that, overwriting the last decoded data. Therefore,
more data is dropped than is necessary. This also leads to a
heap use after free when a buffer resize is needed to accomodate
the silence data and the frame data is used for analysis
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=57354
Return false was used instead of return -1. Also, overflow is
checked with signed int, which triggers the undefined behaviour
sanitizer. Instead, be a little more strict, such large values
aren't useful in this context anyway.
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=58268
manx