avifdec writing PNG returns error

[FrankGalligan]

Steps to reproduce:

1. ./avifenc input.png output.avif
2. ./avifdec output.avif new.png

I get error:
libpng error: profile 'libavif': 49002h: length does not match profile

If I comment out this line:
https://github.com/AOMediaCodec/libavif/blob/main/apps/shared/avifpng.c#L421

Then I do not see the error.

[wantehchang]

Frank: I can't reproduce this bug. Could you provide a sample PNG file? You can email it to me and Yannis. Thanks.

[y-guyon]

I managed to reproduce it internally with avifenc -s 10 tests/data/paris_icc_exif_xmp.png + avifdec with no special flag. It seems to be a heap-use-after-free:

1. avifDecoderParse() called by avifdec calls avifParse().
   1. avifParse() stores the pointer to the icc chunk within the output of decoder->io->read().
      decoder->io->persistent is set to AVIF_FALSE at that time.
2. avifDecoderParse() calls avifDecoderReset().
   1. avifDecoderReset() calls avifDecoderFindMetadata() which calls avifDecoderItemRead(). It uses avifIOFileReaderRead() which extends the output of decoder->io->read() to fit more bytes.
   2. avifDecoderReset() copies the ICC bytes from prop->u.colr.icc (now an invalid pointer) to decoder->image->icc.

Step 1.i. should store the offset instead of the pointer, or copy the bytes immediately.

[wantehchang]

Yannis: Good job tracking this bug down. This kind of memory error is a serious problem. We should take the opportunity to review the relevant code carefully. Do you know why the Exif and XMP metadata are not affected by this bug? It seems that they avoid this bug by either reading the data early or storing the offset (in the avifExtent struct), the same approach you used to fix the bug.

[y-guyon]

I sent #1114 as an attempt to catch this kind of issue, when called by a fuzz target for example. A local run of an internal fuzz target did not report anything. Maybe the CI continuous fuzzing will.

[wantehchang]

Fixed by #1103.