# Google Project Zero Releases MAccConc to Expose Linux Kernel Race Conditions > Learn how to use MAccConc, a new toolkit from Google Project Zero, to explore Linux kernel race conditions using KCOV traces and automated A-B-A testing. - Canonical URL: https://coreiten.com/en/article/google-project-zero-releases-maccconc-to-expose-linux-kernel-race-conditions - Language: en - Section: Linux - Author: Sami - Published: 2026-10-09T12:02:34+03:00 - Modified: 2026-10-09T12:02:34+03:00 - Publisher: CoreITen (https://coreiten.com) - Keywords: MAccConc, KCOV, Google Project Zero, LLVM, Linux kernel, kvmtool ## Summary Google Project Zero released MAccConc, an experimental toolkit utilizing KCOV traces, terminal interfaces, and automated testing to expose elusive Linux kernel race conditions. - The toolkit requires a custom kernel build using an LLVM build at version 23 or higher, or a build from HEAD that includes commit dc5c6d008f48. - Researchers must set specific KCFLAGS and kernel config flags such as CONFIG_SMP=y, CONFIG_KASAN=y, and CONFIG_KCOV=y. - The recommended setup uses kvmtool to boot the custom kernel in a guest environment with the userspace GUI running on the host machine. - Test cases are written in C and must define four specific functions: test_setup(), test_thread1(), test_thread2(), and test_end(). - The kcov-autorace tool automates the exploration of A-B-A execution orderings while kcov-terminal allows manual ordering constraints. - MAccConc is an experimental tool and is not eligible for the Google Open Source Software Vulnerability Rewards Program. **Why it matters:** This toolkit transforms Linux kernel debugging from a probabilistic challenge into a systematic, tool-driven methodology for discovering concurrency vulnerabilities. --- 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](https://bughunters.google.com/open-source-security). ### Kernel and Compiler Requirements 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](https://apt.llvm.org/). The kernel tree must be pulled from the kcov-tracing-full branch at [thejh/linux](https://github.com/thejh/linux). When configuring and building the kernel, specific variables must be set as documented by [kernel.org](https://docs.kernel.org/kbuild/llvm.html) 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: ```bash 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: ```bash # 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: ```bash CONFIG_RCU_EXPERT=y CONFIG_RCU_STRICT_GRACE_PERIOD=y ``` ### Environment Setup and Booting 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. ```bash 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: ```bash 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: ```bash sh-5.3# mount -t debugfs none /sys/kernel/debug sh-5.3# mount -t tmpfs none /tmp sh-5.3# ``` ### Writing and Testing Race Conditions 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(). ```c 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: ```bash $ 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: ```bash $ make testcase/demo-dup-vs-close.so cc -shared -o testcase/demo-dup-vs-close.so testcase/demo-dup-vs-close.c -Wall ``` ### Automated A-B-A Testing 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. ```bash 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(). ```bash 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 Automation of Concurrency Flaws 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. ## Sources - [kitploit.com](https://kitploit.com/en/tools/github/googleprojectzero/maccconc)