Found while fuzzing m-c 20230812-3328121ba1cc (--enable-debug --enable-fuzzing)

To reproduce via Grizzly Replay:

$ pip install fuzzfetch grizzly-framework
$ python -m fuzzfetch -d --fuzzing -n firefox
$ python -m grizzly.replay ./firefox/firefox testcase.avif

Assertion failure: image.primary_image.data, at /builds/worker/checkouts/gecko/image/decoders/nsAVIFDecoder.cpp:272

#0 0x7f44b3ff4536 in mozilla::image::AVIFParser::GetImage(mozilla::image::AVIFImage&) /builds/worker/checkouts/gecko/image/decoders/nsAVIFDecoder.cpp:272:3
#1 0x7f44b3ff7b36 in mozilla::image::nsAVIFDecoder::DoDecodeInternal(mozilla::image::SourceBufferIterator&, mozilla::image::IResumable*) /builds/worker/checkouts/gecko/image/decoders/nsAVIFDecoder.cpp:1465:29
#2 0x7f44b3ff709b in mozilla::image::nsAVIFDecoder::DoDecode(mozilla::image::SourceBufferIterator&, mozilla::image::IResumable*) /builds/worker/checkouts/gecko/image/decoders/nsAVIFDecoder.cpp:1195:25
#3 0x7f44b3f359f0 in mozilla::image::Decoder::Decode(mozilla::image::IResumable*) /builds/worker/checkouts/gecko/image/Decoder.cpp:177:19
#4 0x7f44b3f4f426 in mozilla::image::MetadataDecodingTask::Run() /builds/worker/checkouts/gecko/image/IDecodingTask.cpp:161:34
#5 0x7f44b3f58ce1 in mozilla::image::DecodingTask::Run() /builds/worker/checkouts/gecko/image/DecodePool.cpp:146:12
#6 0x7f44b271f115 in mozilla::TaskController::RunPoolThread() /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:357:33
#7 0x7f44c87c49ef in _pt_root /builds/worker/checkouts/gecko/nsprpub/pr/src/pthreads/ptthread.c:201:5
#8 0x7f44c8494b42 in start_thread nptl/pthread_create.c:442:8
#9 0x7f44c85269ff  misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6312bb43e1366032ad2cb5d14f1e60af45aafb42&tochange=430e71478ff5724ff38501f3c82ccd9a8e4e6887

bug 1788119

Set release status flags based on info from the regressing bug 1788119

:Zaggy1024, since you are the author of the regressor, bug 1788119, could you take a look?

For more information, please visit BugBot documentation.

Zaggy1024, if you prefer, I'm happy to look into this.

Verified bug as reproducible on mozilla-central 20230814214038-27c67d619752.
The bug appears to have been introduced in the following build range:

Start: 8dfe63fbc302f61029f4f652942e4628b4a1b209 (20230127165641)
End: 72da2fb0aab1c5cd50aee0b7759eb4678a2d84b8 (20230127202057)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8dfe63fbc302f61029f4f652942e4628b4a1b209&tochange=72da2fb0aab1c5cd50aee0b7759eb4678a2d84b8

Hi, I am just curious where the testcase.avif came from.

The image would not display in my Chromium (v116) either, and I have tried the validator with it, which gives:

[avif] 3 error(s), 1 warning(s).
[miaf] 1 error(s), 0 warning(s).
[isobmff] 1 error(s), 0 warning(s).

The image came from a fuzzer. It is not expected to display necessarily. It is however expected that we don't assert or crash.

To follow up on the needinfo (sorry for the delay, had account issues):

Looks like the file's primary item (contained in the pitm box) refers to an item with an extent starting at the end of the mdat box, so the size ends up being zero. In mp4parse, that zero-length data gets returned as a null pointer, which Firefox's AVIF decoder doesn't account for.

In my opinion, the mp4parse_avif_get_image() API should guarantee that a primary item is present if no error is returned (as nsAVIFDecoder currently assumes), so there should probably be a few more checks/assertions present there. We should return an error if there is no primary item, and we should be able to guarantee that if context.alpha_item_is_present() is true, we return a non-null Mp4parseByteData for the alpha image.

mp4parse should also return an error in read_avif() (relevant code) in case the primary or alpha items have zero-sized data, as that is never valid. To prevent that case from happening, DataBox.get(Extent) should return None in cases where the slice length is zero, causing the AVIF item location not to be found.

As a quick fix, though, AVIFParser::GetImage() can check whether the data is null and if so return the same error as if the primary item was not present. That check could be removed if mp4parse is changed to guarantee an error instead.

Set release status flags based on info from the regressing bug 1788119

https://hg.mozilla.org/mozilla-central/rev/64af05ee7091

The patch landed in nightly and beta is affected.
:tnikkel, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox119 to wontfix.

For more information, please visit BugBot documentation.

Verified bug as fixed on rev mozilla-central 20231011092203-bbe69c1ce114.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.