Each DNS worker thread lazily initialized its own __res_state via res_ninit(resState.get()) in ResolveHTTPSRecordImpl, and tore it down with res_nclose(res) in DNSThreadShutdown. Although each thread owns its own __res_state, res_ninit/res_nclose reach into shared, process-global resolver state (configuration parsing, file descriptors, internal glibc structures). With multiple DNS threads concurrently entering res_ninit/res_nclose, these calls raced on that shared state, producing the memory corruption the Mozilla fuzzing team observed (CWE-119 buffer bounds error per the advisory, but the diff shows the mechanism is a data race, not a bounds-checking bug).

The fix introduces a file-scope mozilla::StaticMutex sMutex and wraps both resolver calls in critical sections: ResolveHTTPSRecordImpl takes StaticMutexAutoLock lock(sMutex) around the res_ninit call (and its failure return), and DNSThreadShutdown takes the same lock around res_nclose(res). Serializing init/close eliminates the concurrent access to the shared resolver state that led to corruption. Note the lock scopes only the resolver library calls, not the surrounding per-thread bookkeeping, which is the minimal correct fix. The advisory’s generic “memory corruption / buffer bounds error” wording and the diff disagree on class: the diff substantiates a concurrency/race root cause whose consequence is memory corruption, so the operative class is Race.

This affects the process hosting Firefox’s Unix DNS resolution (socket/parent process). No elevated privilege is needed to drive DNS lookups, but reliable exploitation of a resolver-state race into controlled corruption is hard (CVSS AC:H), and the advisory itself only “presumes” code execution is possible. The demonstrated primitive from the diff is a thread-safety violation yielding memory corruption; weaponization into RCE is unproven here and marked inferred. Impact is rated high (C/I/A:H) on the assumption of exploitable corruption.