[flac-dev] Metadata block max size

Ian Nartowicz flac at nartowicz.co.uk
Fri Jun 20 09:17:48 PDT 2014


On Fri, 20 Jun 2014 12:07:31 +0400
lvqcl <lvqcl.mail at gmail.com> wrote:

>Pierre-Yves Thoulon wrote:
>
>> METADATA_BLOCK_HEADER has a 24-bit field to encode the length of
>> METADATA_BLOCK_DATA ; hence the limitation (which not only applies
>> to METADATA_BLOCK_PICTURE but all metadata blocks.
>
>I see. So it's possible to abuse some other metadata blocks too..
>I found the following checks in libFLAC and metaflac sources:
>
>src/libFLAC/metadata_iterators.c, write_metadata_block_header_cb_(...):
>
>     FLAC__ASSERT(block->length < (1u << FLAC__STREAM_METADATA_LENGTH_LEN));
>
>
>
>src/libFLAC/stream_encoder_framing.c, FLAC__add_metadata_block(...):
>
>     FLAC__ASSERT(i < (1u << FLAC__STREAM_METADATA_LENGTH_LEN));
>
>
>
>src/metaflac/options.c, FLAC__bool parse_add_padding(...):
>
>     return *out < (1u << FLAC__STREAM_METADATA_LENGTH_LEN);
>
>_______________________________________________
I haven't found where the out of bounds references occur.  They aren't caught
by those asserts and the code can continue in various ways depending on how big
the block is until something fatal happens.

The problems occur when the metadata blocks are being read by a full decoder
with callbacks.  One symptom is the callbacks being called for more blocks than
exist and with bizarre block properties such as (overflowed?) lengths.

I haven't reported the problem yet because I don't have explicit test cases
(other than a metadata block longer than 16MB) and I was hoping to identify to
location of the problems.

--ian


More information about the flac-dev mailing list