Bugzilla

Running the `ContentParentIPC` target locally, I found out two things first

1) I had to fix some easy null checks that caused immediate crashes (note that this can cause some line numbers in the backtrace to be slightly off).

2) I had to limit the allocation size in the JS engine to a reasonable value, because the fuzzer was creating GB large TypedArrays through StructuredClone deserialization.

Once I did this, I hit the use-after-free attached, which seems to involve an OOM condition (caused by `MOZ_FUZZ_LARGE_ALLOC_LIMIT` in the fuzzing case).

This looks dangerous to me because a compromised parent could easily provoke such an OOM by using really large TypedArrays, leading to a sandbox escape.

So far, I was not able to reproduce the issue reliably with a testcase, but I will continue to work on it and also try it without my fixes on Monday. In the meantime, maybe the uaf trace is already enough to confirm that this is a legit issue and to find the right fix.

Running the `ContentParentIPC` target locally, I found out two things first

1) I had to fix some easy null checks that caused immediate crashes (note that this can cause some line numbers in the backtrace to be slightly off).

2) I had to limit the allocation size in the JS engine to a reasonable value, because the fuzzer was creating GB large TypedArrays through StructuredClone deserialization.

Once I did this, I hit the use-after-free attached, which seems to involve an OOM condition (caused by `MOZ_FUZZ_LARGE_ALLOC_LIMIT` in the fuzzing case).

This looks dangerous to me because a compromised child could easily provoke such an OOM by using really large TypedArrays, leading to a sandbox escape.

So far, I was not able to reproduce the issue reliably with a testcase, but I will continue to work on it and also try it without my fixes on Monday. In the meantime, maybe the uaf trace is already enough to confirm that this is a legit issue and to find the right fix.