graphicsmagick:coder_HEIF_fuzzer: Heap-buffer-overflow in derive_collocated_motion_vectors

[bobfriesenhahn]

OSS-Fuzz issue 390261250 has been open for some time already (since January 16th, 2025). This the original claim:

Crash Type: Heap-buffer-overflow READ 1
Crash Address: 0x51b0000029c6
Crash State:
  derive_collocated_motion_vectors
  derive_temporal_luma_vector_prediction
  fill_luma_motion_vector_predictors

However, OSS-Fuzz says that the issue may be unreproducible with the test case. In CMakeLists.txt I see that threads are required. Local testing with the provided test case shows a wide variety of behaviors. Valgrind testing screams about use of uninitialized values. Results from daily oss-fuzz test runs show a wide variety of behaviors. A very disturbing behavior is that it seems that when a thread allocates memory, it does not free its own memory. The memory allocated by one thread is instead freed by another. This is a a poor memory allocation methodology given that it makes it more difficult to track memory allocations, and that some OS implementations optimize by creating per-thread pools so it is more efficient for a thread to deallocate the memory that it allocated, or for the memory to be allocated for all threads by one thread in advance, and then deallocated by that same thread at the end (to avoid blocking on locks).

The test case is provided here (with bogus jpg extension) in case it is useful. When testing with GraphicsMagick it is necessary to force "HEIF" input format. For example:

gm convert heif:clusterfuzz-testcase-coder_HEIF_fuzzer-6662197333262336 info:-