Google Project Zero Releases MAccConc to Expose Linux Kernel Race Conditions

Linux kernel developers and security researchers struggling to isolate elusive race conditions now have a powerful new weapon. Google Project Zero has released MAccConc, a specialized toolkit designed to expose concurrent execution flaws and memory access overlaps using KCOV traces. Race conditions are notoriously difficult to reproduce and debug, often requiring complex setups to force specific execution orderings.

MAccConc addresses this by providing both graphical and terminal interfaces to visualize these overlaps, alongside automated testing for A-B-A execution orderings. Note that this is an experimental tool and is not eligible for the Google Open Source Software Vulnerability Rewards Program.

To use MAccConc, researchers must compile a custom kernel. It requires an LLVM build at version 23 or higher, or a build from HEAD that includes commit dc5c6d008f48. These builds are available via apt.llvm.org. The kernel tree must be pulled from the kcov-tracing-full branch at thejh/linux.

When configuring and building the kernel, specific variables must be set as documented by kernel.org to ensure the correct toolchain is applied. Set the following environment variable to clarify executed basic blocks and avoid confusing call stacks due to tail call optimization:

export KCFLAGS="-fno-optimize-sibling-calls -mllvm -sanitizer-coverage-prune-blocks=false"

Ensure that the following kernel config flags are set, either through the ncurses configuration UI or by pasting them at the bottom of the.config file:

# for core functionality
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
CONFIG_KALLSYMS_ALL=y

# to give the GUI information about source lines and inlining
CONFIG_DEBUG_INFO_DWARF5=y

# for communicating with the GUI
CONFIG_VSOCKETS=y
CONFIG_VIRTIO_VSOCKETS=y
CONFIG_VIRTIO_PCI=y

# for maximizing the potential for race conditions
CONFIG_PREEMPT=y

# for making virtual addresses at runtime the same as in vmlinux
CONFIG_RANDOMIZE_BASE=n

# needed for several samples
CONFIG_TMPFS=y

You can also enable the following flags to test race conditions involving RCU, though this will cause a significant slowdown and currently only works properly with the GUI:

CONFIG_RCU_EXPERT=y
CONFIG_RCU_STRICT_GRACE_PERIOD=y

The toolkit is designed to run the userspace GUI on the host machine while the custom kernel boots in a guest environment. The recommended approach is to install kvmtool rather than a standard QEMU VM.

git clone https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git
cd kvmtool
make
make install

Once installed, you can boot the built kernel using the following command, which provides a shell with a read-only view of the host filesystem mounted at /host:

lkvm run --kernel [path to kernel tree]/arch/x86/boot/bzImage --vsock 5 --console virtio

After each boot, you must manually mount debugfs and tmpfs in the guest environment:

sh-5.3# mount -t debugfs none /sys/kernel/debug
sh-5.3# mount -t tmpfs none /tmp
sh-5.3#

Test cases are written in C and must define four specific functions to structure the execution flow. For every execution, test_setup() runs first, followed by test_thread1() and test_thread2() in parallel, concluding with test_end().

void test_setup(void) { [...] }
void test_thread1(void) { [...] }
void test_thread2(void) { [...] }
void test_end(void) { [...] }

These test cases should be built as shared libraries on the host machine:

$ cc -shared -o [name].so [name].c -fPIC

The sample test cases provided in the repository's testcase folder can also be built via make:

$ make testcase/demo-dup-vs-close.so
cc -shared -o testcase/demo-dup-vs-close.so testcase/demo-dup-vs-close.c -Wall

The kcov-autorace tool automates the exploration of A-B-A execution orderings. In these scenarios, thread A runs up to a specific point, thread B executes fully, and then thread A finishes its execution.

sh-5.3# cd /host/{path to checkout on the host}
sh-5.3# ./kcov-autorace testcase/demo-dup-vs-close.so
loading kallsyms
RCU state (excluded): base=ffffffff82770100 len=500
loading testcase
initializing kcov
collecting A-B coverage
dup(5) = 6 (success)
testing candidates
dup(5) = -1 (Bad file descriptor)
dup(5) = -1 (Bad file descriptor)
dup(5) = -1 (Bad file descriptor)
dup(5) = 5 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
stats:  injection-failed:0  wait-timeout:7  reordered:4
sh-5.3#

For manual ordering constraints, the kcov-terminal tool allows researchers to specify "A should happen before B" rules. This is useful for demonstrating non-atomic operations, such as reading UID and GID via fstat() against fchown().

sh-5.3# ./kcov-terminal testcase/demo-inode-attr-change.so
uid=0 gid=0
=====  filtered to interference set, no RCU core  =====
LEGEND:
  type: R=read  W=write  M=modify(read+write)  F=free  A=atomic

The release of MAccConc by Google Project Zero shifts kernel debugging from a purely manual, intuition-based process to a deterministic, tool-driven methodology. By forcing specific A-B-A execution orderings and visualizing memory access overlaps through KCOV traces, researchers can now systematically prove race conditions that previously relied on statistical probability to trigger.

The strict requirement to disable CONFIG_RANDOMIZE_BASE and compile features directly into the kernel rather than as modules highlights the absolute environmental control needed to achieve this determinism. This toolkit will likely accelerate the discovery of concurrency vulnerabilities in core Linux subsystems, particularly those involving complex file descriptor operations like dup and close.