MAccConc from Google Project Zero is a research toolkit for replaying and forcing specific thread orderings in the Linux kernel, built for authorized vulnerability research and kernel debugging.

MAccConc is the newest release from Google Project Zero, and it addresses one of the oldest and most painful problems in kernel security research: concurrency. The repository describes itself as tooling for exploring Linux kernel race conditions and for general kernel debugging, and it ships three components: a GUI for viewing KCOV traces of kernel execution and memory accesses with a focus on concurrent execution, a terminal UI (kcov-terminal) with the same core functionality but fewer features, and kcov-autorace, a helper that automatically tests possible A-B-A orderings of a given testcase. The project is written primarily in C++, carries an Apache-2.0 license, and is accompanied by an announcement post on projectzero.google that provides the research narrative behind the code. It is explicitly not an officially supported Google product, which is standard framing for Project Zero research artifacts.

The architectural premise is what makes this toolkit interesting. Rather than hoping to win a race by hammering a syscall in a loop thousands of times, MAccConc instruments the kernel to record per-thread execution traces and memory accesses through an extended KCOV interface, then lets the researcher force specific interleavings deterministically. The README shows test cases as C code defining four functions: test_setup(), test_thread1(), test_thread2(), and test_end(). For every execution, test_setup() runs first, the two thread functions run in parallel, and test_end() runs last. Testcases are compiled as shared libraries with cc -shared -o [name].so [name].c -fPIC, and samples in the testcase/ folder such as demo-dup-vs-close and demo-inode-attr-change can be built directly via make.

Getting the instrumented kernel running is the bulk of the setup effort, and the README is refreshingly detailed about it. You need an LLVM build that includes commit dc5c6d008f48, meaning a build from HEAD or at version >=23, obtainable from apt.llvm.org. The kernel itself comes from a patched tree at github.com/thejh/linux, branch kcov-tracing-full, which extends KCOV with the execution and memory-access recording the viewers depend on. The README also recommends exporting KCFLAGS="-fno-optimize-sibling-calls -mllvm -sanitizer-coverage-prune-blocks=false" so that basic-block information stays legible and tail-call optimization does not produce misleading call stacks in the GUI.

The required kernel configuration reads like a checklist of kernel-instrumentation primitives. Core functionality demands CONFIG_SMP=y, CONFIG_NR_CPUS=4, CONFIG_KASAN=y, CONFIG_KASAN_OUTLINE=y, CONFIG_KCOV=y, CONFIG_KCOV_EXT_RECORDS=y, CONFIG_KCOV_MEMORY=y, and CONFIG_KALLSYMS_ALL=y. The GUI needs CONFIG_DEBUG_INFO_DWARF5=y for source-line and inlining information, and CONFIG_VSOCKETS=y with CONFIG_VIRTIO_VSOCKETS=y and CONFIG_VIRTIO_PCI=y for host-guest communication. CONFIG_PREEMPT=y maximizes the potential for race conditions to manifest, CONFIG_RANDOMIZE_BASE=n keeps runtime virtual addresses aligned with those in vmlinux, and CONFIG_TMPFS=y is needed by several samples. An optional CONFIG_RCU_EXPERT=y plus CONFIG_RCU_STRICT_GRACE_PERIOD=y pair enables testing RCU-involving races at the cost of significant slowdown, and only works properly with the GUI. The README also insists that kernel features under test be compiled in rather than built as modules.

The userspace tooling is meant to be built on the host, not the guest, particularly the GUI. On Debian, the dependency set is git, build-essential, pkg-config, libcapstone-dev, libdw-dev, and libglfw3-dev, pulled in with sudo apt install git build-essential pkg-config libcapstone-dev libdw-dev libglfw3-dev. After cloning, git submodule update --init --recursive fetches dependencies and a plain make builds everything. The choice of libcapstone and libdw tells you the viewers disassemble and symbolize kernel code paths locally, while glfw3 indicates a lightweight OpenGL-based GUI rather than a browser frontend.

For booting the research kernel, the README recommends kvmtool over a full QEMU setup, cloned from the kernel.org tree and installed via its own make and make install. The kernel is then booted with lkvm run --kernel [path]/arch/x86/boot/bzImage --vsock 5 --console virtio, which starts the guest with a vsock channel for GUI communication and a minimal rootfs of symlinks into a read-only host view mounted at /host over 9p filesystems. Two manual steps per boot are required: mounting debugfs at /sys/kernel/debug and tmpfs at /tmp. This is a lab-only environment by construction, which suits the tool's authorized-research purpose.

The kcov-autorace component is the automation highlight. An A-B-A ordering is one where thread A runs partway, thread B executes fully, and then thread A finishes — a classic pattern for refcount and file-descriptor lifetime bugs. Running ./kcov-autorace testcase/demo-dup-vs-close.so in the guest collects coverage, enumerates candidate interleavings, and reports per-candidate syscall results plus stats such as injection-failed, wait-timeout, and reordered counts. The README's demo output shows dup(5) returning 5 under one specific reordering instead of a fresh descriptor, demonstrating a close(5) versus dup(5) race without the researcher writing any scheduler manipulation code. One caveat documented in the README: all tools use a hardcoded spin-wait timeout, SPIN_LIMIT, which bounds how long injection points can stall a thread.

The terminal workflow in kcov-terminal is where the analytical power lives. It runs a testcase with manually specified ordering constraints expressed as "A should happen before B" rules over memory-access IDs rather than a full linear order. The README's worked example uses testcase/demo-inode-attr-change.so to show that fstat()'s reading of UID and GID is not atomic with respect to fchown(). The trace view renders each access with an ID like B0002 or A0003, a data address, size, and type — R for read, W for write, M for modify, F for free, A for atomic — interleaved against the symbolized call stacks of both threads, from __x64_sys_newfstat down through generic_fillattr and shmem_setattr. Adding constraints such as B0002 before A0002 and A0003 before B0003 then deterministically produces uid=0 gid=1, a torn read of inode attributes, visible directly in the follow-up trace.

For defenders and kernel maintainers, the value of MAccConc is as a root-cause machine. Races like the fstat()/fchown() attribute tear or the dup()/close() descriptor reuse are exactly the class of bug that manifests as heisenbug reports and occasional privilege-relevant misbehavior in production. By turning a nondeterministic scheduling lottery into an enumerable set of candidate orderings with explicit pass/fail outcomes, the toolkit lets a maintainer reproduce, understand, and verify a fix for a concurrency defect inside an afternoon instead of a week of loop-hammering. It fits squarely in an authorized workflow of kernel hardening, patch validation, and upstream vulnerability research conducted entirely in researcher-controlled virtual machines.

The operational overhead should not be understated. You are building a bleeding-edge LLVM toolchain, a patched out-of-tree kernel branch, and a custom VM environment before the first trace appears, and the RCU modes carry a large performance penalty. The README is honest about limitations beyond SPIN_LIMIT, noting the terminal UI is deliberately a reduced-feature sibling of the GUI and that the project sits outside Google's official support and vulnerability-reward scope. For teams already invested in kernel fuzzing infrastructure, however, MAccConc is a natural complement to tools like syzkaller: where fuzzers discover suspicious concurrent code paths, this toolkit explains and proves them, making it a significant addition to the concurrency-research toolbox.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• Agentic-Bug-Hunter for AI-driven reconnaissance and bug bounty reporting


• nginx-ultimate-bad-bot-blocker for filtering malicious bots, scrapers and spam referrers at the edge