Bug 263913 – WebAssembly memory corruption on arm64 macOS and iOS

• Status: RESOLVED
• Resolution: FIXED
• Component: WebAssembly

[Brooke Vibber]

While testing my WebAssembly media codecs library, I found that the AV1 decoder is failing in at least some cases on ARM64 Macs and iPhones running Safari, while it works as expected on x86_64 Macs and in Firefox or Chrome on ARM64 Macs.

The symptom is a failure of call_indirect signature validation, which likely indicates corruption of a function pointer via some earlier error.

I haven't been able to narrow down where/how exactly in the dav1d codec library code it's corrupting data, but have a very stable test case with a .wasm file, two packets of input data, and the surrounding JavaScript wrapper from emscripten:

Live test case: https://brionv.com/misc/wasm-safari-bug/


Test case with all component parts ready to run in a git repo: https://github.com/brion/wasm-safari-bug

Compiling dav1d with -O2 or -Os avoids the bug, but since it runs correctly in other browsers and in WebKit on x86_64 I think it's not likely to be a clang/llvm issue.

[Radar WebKit Bug Importer]

<rdar://problem/117804393>

[Mark Lam]

Hi Brion, which version of WebKit did you saw this issue on?  Is it the Safari 17 that came with a macOS install (which one)?  Or is it on a local WebKit build?

[Brooke Vibber]

(In reply to Mark Lam from comment #2)
> Hi Brion, which version of WebKit did you saw this issue on?  Is it the
> Safari 17 that came with a macOS install (which one)?  Or is it on a local
> WebKit build?

I have so far reproduced it in:

* macOS 14.1's stock Safari
* iOS 17.1's stock Safari
* a local WebKit build from main a few days ago
* WebKit nightly builds from a few days ago, 3 months ago, and 6 months ago

[Brooke Vibber]

Also the current Safari Technology Preview exhibits the bug on my M1 MacBook Air.

[Justin Michaud]

You are right, this is a JSC bug.

Thank you so much for reporting this, and for making such a tidy reproduction repo. I cannot explain how much easier that makes this.

I was able to reproduce on a very recent nightly build. This configuration also makes the issue go away:

 __XPC_JSC_useBBQJIT=0 __XPC_JSC_useConcurrentJIT=0 run-safari -ExtensionsEnabled NO

This of course reproduces the issue:

__XPC_JSC_useBBQJIT=1 __XPC_JSC_useOMGJIT=0 __XPC_JSC_useConcurrentJIT=0 run-safari -ExtensionsEnabled NO

This looks like a BBQ bug, which is our new baseline compiler tier that was introduced in macOS 17.

Thanks again, I will try to bisect which function is the cause.

[Brooke Vibber]

(In reply to Justin Michaud from comment #5)
> You are right, this is a JSC bug.
> 
> Thank you so much for reporting this, and for making such a tidy
> reproduction repo. I cannot explain how much easier that makes this.
...
> This looks like a BBQ bug, which is our new baseline compiler tier that was
> introduced in macOS 17.
> 
> Thanks again, I will try to bisect which function is the cause.

oh good I'm glad the repro is workable! it's always tough chopping down these big code blobs ;) :D

[Justin Michaud]

Hey! Thank you so much for this repro case, it was very helpful in determining the root cause of a few different bugs. Sorry for the delay in responding publicly.

The fix was landed here: https://github.com/WebKit/WebKit/pull/22029

Cheers!

[Brooke Vibber]

Woohoo! Thanks for the fix. :D