Project Zero's MAccConc: Making Race Conditions Reproducible for Testing
Google Project Zero has released MAccConc, a tool that pairs memory-access tracing with stack-based delay injection to reliably reproduce thread interleavings — turning notoriously flaky race-condition bugs into repeatable test cases.
Key Takeaways
- MAccConc, published by Jann Horn at Google Project Zero, uses ASAN-based memory access tracing plus KCOV to identify concurrent "communication points" between threads.
- A stack-based delay-injection mechanism — enforced via a new KCOV_SET_DI ioctl — lets testers force a specific thread interleaving on demand, turning a once-in-a-thousand-runs race into a deterministic repro.
- The tool is open-sourced but early-stage: it needs LLVM 23.1.0+ and a custom Linux kernel branch, with the kernel-side patches still pending upstream review.
- It targets three long-standing pain points — confirming manually found race candidates, writing regression tests for fixed races, and giving fuzzers a way to steer interleavings instead of hoping for the right one.
A structural answer to a notoriously flaky bug class
Race conditions are among the hardest security bugs to work with, not because they're rare but because they're non-deterministic: the same code can run correctly a thousand times and then fail once, depending on exactly how threads interleave. That makes them hard to confirm when found by manual review or static analysis, hard to write regression tests for after a fix, and hard for fuzzers to reach at all, since fuzzing typically has no way to steer *when* one thread runs relative to another.
On 8 September 2026, Google Project Zero's Jann Horn published a detailed writeup introducing MAccConc ("Memory Access Concurrency"), a tool built to make thread interleavings controllable rather than left to chance. The project is open-sourced on GitHub.
How it works
MAccConc combines two mechanisms. The first is memory access tracing: it uses AddressSanitizer instrumentation in outline mode, tied into the Linux kernel's KCOV coverage-tracing mechanism, to record which memory locations each thread touches during a run. From that trace it derives "communication points" — places where two threads' memory accesses overlap and at least one of them is a write, which is exactly where a race condition would need to occur.
The second is stack-based delay injection. To identify a specific memory access reliably across repeated runs — even as code paths shift slightly — MAccConc uses what Horn calls count-augmented stack traces: "each stack trace element essentially consists of a callee function address and a number indicating how many calls to this callee should be skipped in the calling stack frame." A new KCOV_SET_DI ioctl then uses that identifier to pause or release a thread at exactly the right instruction, forcing a chosen ordering instead of hoping the scheduler cooperates.
- An automatic A-B-A interleaving tester that systematically tries different orderings between two threads
- A terminal UI for manually exploring and constraining interleavings
- A GUI for interactively specifying which orderings to force
A concrete example: dup() and close() racing
Horn's writeup demonstrates the approach against concurrent dup(5) and close(5) calls on the same file descriptor. Using MAccConc, the tool surfaced multiple valid interleavings — including one where dup() ends up returning file descriptor 5 again, immediately after a concurrent close() freed it. It's a small example, but it's exactly the kind of file-descriptor-reuse race that has underpinned real kernel exploits, and it shows the tool forcing an ordering that would otherwise require luck to hit.
What it means in practice
This is not a turnkey scanner. It currently requires LLVM 23.1.0 or later (for the PC-tracing support it depends on) and a custom Linux kernel branch, since the kernel-side patches enabling KCOV_SET_DI have not yet landed upstream. That puts it squarely in research-tooling territory for now — most useful to teams doing kernel or systems-level concurrency review, not something you drop into an existing CI pipeline this week.
The idea generalizes beyond the kernel, though. Anywhere multi-threaded code has a suspected race — device drivers, hypervisors, security-critical userspace daemons — the same pattern of "trace accesses, then forcibly reproduce the interleaving" turns a bug that's hard to even confirm exists into a deterministic test case. For security teams doing code review or building internal fuzzing infrastructure around concurrency-heavy components, it's worth tracking as the upstream kernel patches mature.
Frequently Asked Questions
What is MAccConc?
MAccConc ("Memory Access Concurrency") is a race-condition testing tool released by Google Project Zero researcher Jann Horn. It traces memory accesses across threads and can force a chosen execution ordering, making previously flaky race conditions reproducible on demand.
How does MAccConc force a specific thread interleaving?
It identifies memory accesses using count-augmented stack traces — a callee address plus a skip-count — and uses a new Linux kernel ioctl, KCOV_SET_DI, to pause or release threads at that exact point, enforcing the desired ordering instead of relying on scheduler luck.
Can I use MAccConc today in a production CI pipeline?
Not yet in a fully self-contained way. It requires LLVM 23.1.0 or later and a custom Linux kernel branch, since the kernel patches enabling the delay-injection ioctl are still pending upstream review.
Sources
- 1MAccConc: Testing race conditions with memory access tracing and stack-based delay injection — Google Project Zero
- 2googleprojectzero/MAccConc — GitHub