Cool regardless.

Obviously nobody is really using Ladybird yet and there will be many more such issues to address, so now is a good time to evaluate how to avoid such mistakes up front.

That's something that you use fuzzing as one way to detect a failure of, not as the means of achieving correctness and security.

I'm not picking on Ladybird here specifically. Chrome and Firefox provide constant streams of security vulnerabilities. But it would be nice if Ladybird didn't start with the same problems that might be attributed to huge legacy code bases.

The main solutions seem to be either restricting how possibly-invalidated data can be held (e.g., safe references in Rust), or having some coloring scheme (e.g., "pure" annotations) to ensure that the functions you call are unable to affect your data. Immutable languages can mitigate it somewhat, but only if you have the discipline to maintain a single source of truth for everything, and avoid operating on stale copies.

The Ladybird codebase is generally very defensive, but like every browser, our JavaScript engine is slightly less so (in the pursuit of performance.)

There are architectural lessons to learn here beyond just fixing the bugs found. We've since replaced these allocations (+ related ones) with callee-specific stack memory instead of trying to be clever with heap allocation reuse.

We're also migrating more and more of our memory management to garbage collection, which sidesteps a lot of the traditional C++ memory issues.

As others have mentioned, sandboxing & site isolation will make renderer exploitation a lot less powerful than what's demonstrated here. Even so, we obviously want to avoid it as much as possible!