1819796 - gecko/third_party/dav1d/src/refmvs.c:726:37: runtime error: index -29 out of bounds for type 'const int[7]'

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Tyson Smith [:tsmith]]

Found while fuzzing m-c 20230301-d59b76766f0d (--enable-undefined-sanitizer --enable-fuzzing)

This has been reported by fuzzers running 32 bit builds. Unfortunately I don't have a reliable test case at the moment. I will attach one if one becomes available. Stack looks close to bug 1814790, possibly related?

/builds/worker/checkouts/gecko/third_party/dav1d/src/refmvs.c:726:37: runtime error: index -29 out of bounds for type 'const int[7]'
    #0 0xe549613b in dav1d_refmvs_load_tmvs /builds/worker/checkouts/gecko/third_party/dav1d/src/refmvs.c:726:37
    #1 0xe53b38f8 in dav1d_decode_tile_sbrow /builds/worker/checkouts/gecko/third_party/dav1d/src/decode.c:2832:9
    #2 0xe549ec1a in dav1d_worker_task /builds/worker/checkouts/gecko/third_party/dav1d/src/thread_task.c:761:33
    #3 0x56736d09 in __asan::AsanThread::ThreadStart(unsigned long long) /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/asan_thread.cpp:277:25
    #4 0x5671201e in asan_thread_start(void*) /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:199:13
    #5 0xf79e9b90  (/lib/i386-linux-gnu/libc.so.6+0x86b90) (BuildId: 0494f075afbcfa9004eaaedccbea53807b7bf669)
    #6 0xf7a8664b  (/lib/i386-linux-gnu/libc.so.6+0x12364b) (BuildId: 0494f075afbcfa9004eaaedccbea53807b7bf669)

Comment 1

[Tyson Smith [:tsmith]]

Note: This was found via the UBSan bounds check.

Comment 2

[Tyson Smith [:tsmith]]

Attachment: harness.html

Comment 3

[Tyson Smith [:tsmith]]

Attachment: testcase.avif

STR:

• download harness.html and testcase.avif
• place files in the same directory
• open harness.html in Firefox
• wait... I can repro in < 10 seconds.

Note:
Again this requires a 32 bit build with UBSan.

To download a build using fuzzfetch:

$ pip install fuzzfetch
$ python -m fuzzfetch -a --cpu x86 --fuzzing -n firefox

To build yourself add --enable-undefined-sanitizer to your mozconfig.

Comment 4

[Tyson Smith [:tsmith]]

This test case also triggers bug 1814560 with a debug build (64 or 32 bit).

Comment 5

[Ronald S. Bultje]

I created a 32bit+ubsan+debug dav1d build and again converted the .avif to .ivf with ffmpeg -c:v copy, and cannot reproduce. I really think the conversion in FFmpeg from .avif to .ivf destroys some of the data, so I'll need a way to reproduce this that supports .avif input but does not require me to download all of Firefox. Please try to work on a way of reproducing this using e.g. just libavif.

Comment 6

[Timothy Nikkel (:tnikkel)]

Thanks for attempting to reproduce.

Comment 7

[Ronald S. Bultje]

Adding an .avif demuxer to dav1d would be fine also, by the way, but I think that'll be more effort and it's possible it'll still not reproduce all of these issues because of API usage differences between tools/dav1d vs. libavif or because tools/dav1d would skip the alpha channel.

Comment 8

[Tyson Smith [:tsmith]]

I was able to reproduce the issues with a 64 bit build.

A Pernosco session is available here: https://pernos.co/debug/_Wi3HeW-E5GBgSi-KrS67Q/index.html

Comment 9

[Timothy Nikkel (:tnikkel)]

Similar to bug 1814790, comment 26, I confirmed in the pernosco that we hit the same "wrongly report success but we should have error'ed out" race condition, and then we hit the problem here in the same Dav1dFrameContext. So this likely also has the same root cause.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:aosmond, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 11

[Timothy Nikkel (:tnikkel)]

Bug 1816484 landed which should fix this. Tyson can you confirm? Thanks!

Comment 12

[Tyson Smith [:tsmith]]

I am no longer able to reproduce this issue.

Comment 13

[Timothy Nikkel (:tnikkel)]

Thanks! Let's call it fixed by bug 1816484 then.