Use of invalid enumeration value in aom_push_data2() (oss-fuzz 470722034)

[bobfriesenhahn]

Due to GraphicsMagick oss-fuzz testing, issue 470722034 appeared, which is about a use of an invalid enumeration value in aom_push_data2(). It would be nice if this could be cleaned up.

This is the reported stack trace:

/src/libheif/libheif/plugins/decoder_aom.cc:256:3: runtime error: load of value 242, which is not a valid value for type 'aom_color_primaries_t' (aka 'enum aom_color_primaries')
#0 0x5d2c1aa35bff in get_next_image_from_decoder(aom_decoder*, void const**, heif_image**, unsigned long*, heif_security_limits const*) libheif/libheif/plugins/decoder_aom.cc:256:3
#1 0x5d2c1aa35bff in aom_push_data2(void*, void const*, unsigned long, unsigned long) libheif/libheif/plugins/decoder_aom.cc:338:22
#2 0x5d2c1a950004 in Decoder::decode_sequence_frame_from_compressed_data(bool, heif_decoding_options const&, unsigned long, heif_security_limits const*) libheif/libheif/codecs/decoder.cc:361:11
#3 0x5d2c1a951f35 in Decoder::decode_single_frame_from_compressed_data(heif_decoding_options const&, heif_security_limits const*) libheif/libheif/codecs/decoder.cc:438:23
#4 0x5d2c1a6c9488 in ImageItem::decode_compressed_image(heif_decoding_options const&, bool, unsigned int, unsigned int) const libheif/libheif/image-items/image_item.cc:944:19
#5 0x5d2c1a6c2614 in ImageItem::decode_image(heif_decoding_options const&, bool, unsigned int, unsigned int) const libheif/libheif/image-items/image_item.cc:707:60
#6 0x5d2c1a8b66e6 in HeifContext::decode_image(unsigned int, heif_colorspace, heif_chroma, heif_decoding_options const&, bool, unsigned int, unsigned int) const libheif/libheif/context.cc:1299:34
#7 0x5d2c1a6a646b in heif_decode_image libheif/libheif/api/libheif/heif_decoding.cc:245:81
#8 0x5d2c1a4cb557 in ReadHEIFImageFrame /src/graphicsmagick/coders/heif.c:1093:17
#9 0x5d2c1a4c9c1e in ReadHEIFImage /src/graphicsmagick/coders/heif.c:1792:10
#10 0x5d2c1a398004 in ReadImage /src/graphicsmagick/magick/constitute.c:1682:13
#11 0x5d2c1a367fda in BlobToImage /src/graphicsmagick/magick/blob.c:785:13
#12 0x5d2c1a2f38d5 in Magick::Image::read(Magick::Blob const&) /src/graphicsmagick/Magick++/lib/Image.cpp:1592:5
#13 0x5d2c1a2e787c in LLVMFuzzerTestOneInput /src/graphicsmagick/fuzzing/coder_fuzzer.cc:24:11
#14 0x5d2c1a23e85d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:619:13
#15 0x5d2c1a2295d2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:329:6
#16 0x5d2c1a22f4a0 in fuzzer::FuzzerDriver(int*, char***, int ()(unsigned char const, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:865:9
#17 0x5d2c1a25afd2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#18 0x7c6ad14ba082 in __libc_start_main /build/glibc-B3wQXB/glibc-2.31/csu/libc-start.c:308:16
#19 0x5d2c1a2226bd in _start

These security limits are applied:

max_image_size_pixels = 4194304, max_number_of_tiles = 16777216, max_bayer_pattern_pixels = 256, max_items = 1000, max_color_profile_size = 104857600, max_memory_block_size = 268435456, max_components = 256, max_iloc_extents_per_item = 32, max_size_entity_group = 64, max_children_per_box = 100, max_total_memory = 268435456, max_sample_description_box_entries = 1024, max_sample_group_description_box_entries = 1024

Two files to reproduce the issue are attached.

clusterfuzz-testcase-coder_TIFF_any_fuzzer-4620133932007424.avif.gz

clusterfuzz-testcase-minimized-coder_TIFF_any_fuzzer-4620133932007424.gz

[farindk]

Isn't that the same as #1634 ?

[bobfriesenhahn]

The description of #1634 sounds the same, yet oss-fuzz determined that some change made the specific test case stop failing.

[farindk]

I've reorganized the code in the aom decoder plugin. Thus, the line numbers changed and the call hierarchy is slightly different. That might have caused the old issue to be closed and this (same problem) be opened.

[bobfriesenhahn]

Oss-fuzz uses the stack back-trace to identify the origin of issues so it is likely to close an issue if the stack back-trace changes. Regardless, oss-fuzz 470722034 is still open.