kAFL: fuzzing a whole VM with hardware assisted feedback

A fuzzer that treats the machine as the target

kAFL, together with Nyx, is described as a fast guided fuzzer for the x86 VM, and the README says it is great for anything that executes as a QEMU or KVM guest, in particular x86 firmware, kernels and full-blown operating systems. That framing is the whole design. Instead of compiling your target with coverage instrumentation, the fuzzer runs the target inside a virtual machine and observes the machine from the outside, which is why a kernel or a UEFI image is a reasonable input at all. The README also carries a disclaimer that should be read first, that all components are provided for research and validation purposes only and to use at your own risk. The documentation lives on its own site, intellabs.github.io/kAFL, and the project is published to Docker Hub as intellabs/kafl, with a release badge for the GitHub releases and a CI badge for the workflow.

The targets that have already been through it

The list of successful targets is the best available evidence of what the fuzzer can handle, and it spans a wide range. The primary user is the main fuzzer driving the Linux Security Hardening for Confidential Compute effort, identifying vulnerabilities in a complex setup and improving the security of the Linux kernel for all confidential computing solutions. Beyond that, the README lists Intel SGX enclaves, Intel TDX TDVF firmware, Mozilla Firefox IPCs, Linux network applications, Windows drivers and hypervisors, and it does so with the flourish that the fuzzer can play Super Mario at 10 to 30 times speedup, a good summary of what a fast reset loop buys you. It also notes that kAFL has been used internally at Intel for x86 firmware and drivers validation as well as SMM handler fuzzing, so the tool is used in anger on the vendor's own products.

Why the hardware features are the whole trick

The Features section explains the mechanism. kAFL and Nyx use Intel VT, Intel PML, which is page modification logging, and Intel PT, and they do so to achieve efficient execution, snapshot reset and coverage feedback for greybox or whitebox fuzzing scenarios. The consequence the README highlights is reach, since it allows many x86 firmware and OS kernels to be run with any desired toolchain and minimal code modifications. That phrase, minimal code modifications, is the practical difference from an instrumented build. Page modification logging is what makes the dirty page tracking cheap, since the hypervisor learns which pages changed without instrumenting the guest, and Intel PT is what supplies the control flow coverage that turns a random input into a guided one. The repository topics follow the same line, with firmware, fuzzing, kvm, qemu, kernel, redqueen, grimoire, validation and research.

The fuzzer is Python, the extensions do the clever work

The core fuzzer is a separate project, kAFL-Fuzzer, written in Python, and the README says it follows an AFL-like design while being optimised for working with many QEMU instances in parallel, with flexible VM configuration and logging and debug options. Around that sit three pieces that do the interesting work. Radamsa is integrated as a general purpose mutation engine. Redqueen uses VM introspection to extract runtime inputs to conditional instructions, which gets past the typical magic byte and other input checks that stop a blind fuzzer at the first comparison. Grimoire attempts to identify keywords and syntax from fuzz inputs so that it can generate more clever large-scale mutations, so it learns the grammar of the input while the fuzzer runs. The README also points to IJON and to Nyx for detail, with the documentation for those hosted on nyx-fuzz.com.

The host requirements are the real constraint

The Requirements section is where a project like this either works for you or does not, and it is specific. You need an Intel Skylake or later CPU, a Gen-6 or newer Intel part for Intel PT, and adequate system memory at roughly 2GB of RAM per CPU. You also need a patched host kernel, since a modified Linux host kernel is installed as part of the setup, and the README adds that running kAFL inside a virtual machine may work starting from an IceLake or later CPU. The operating system side is the friendliest requirement, since the installation and tutorials are tested for recent Ubuntu LTS, 20.04 or newer, and Debian, bullseye or newer. The patched host kernel deserves a second look, because the machine you fuzz from is then not running a stock kernel, and the setup may ask for a reboot.

Installing with make deploy, and what to fuzz first

Installation needs python3-venv and make, and the README gives the sequence directly:

sudo apt install python3-venv make git
git clone https://github.com/IntelLabs/kAFL.git
cd kAFl
make deploy

Two things to note in that snippet. The directory name in the README is written kAFl, while the clone step creates a directory called kAFL, so the cd will fail unless you correct the spelling. And the README warns that installation may take some time and require a reboot in order to update your kernel. If the automated path goes wrong, the installation guide and the deployment guide cover the details and the customisation of a setup for your project. For a first target, the project recommends fuzzing the Linux kernel, and the other available paths are Windows driver and userspace targets, Linux userspace and UEFI OVMF, with the target material kept in the separate kafl.targets repository, and the README notes that improved documentation for these targets is still being written.

The Makefile is the deployment front end

The Makefile at the root is a thin wrapper over the deployment scripts in the deploy directory, and its help text is the fastest way to see the whole surface. There are five targets, and the user actions are deploy for a full installation that downloads, builds and installs, env to activate the installation with the shell environment and the Python virtual environment, and clean to purge the Ansible installation so you can force a re-deploy. The developer actions are update, which pulls the latest changes from all components, and build, which runs only the component build steps. The wrapper also has a small trick to pass extra arguments to the underlying make invocation. The Dockerfile shows the container route, building on python:3.11-slim-bookworm, skipping Ghidra because it adds a gigabyte to the image, and compiling the fuzzer into a single file with PyInstaller. The maintainers are Mathieu Tarral and Steffen Schulz, the licence is MIT, the releases are v0.8 from October 2023, v0.9 from July 2024 and v0.9.1 from March 2025, and the last push was on 2026-06-19 with the repository not archived.

Editorial conclusion

kAFL fits a security team validating a guest operating system, a firmware image or a hypervisor where source level instrumentation is impossible and where crashing the whole machine is the point. It is the wrong choice for a library or a userspace service, because a full virtual machine per test case is a heavy price, and it is a poor fit if your hardware is not an Intel part with the required page modification logging, since the snapshot mechanism depends on it. Before you plan a campaign, confirm the CPU generation and the free memory, read the deployment guide for what the patched host kernel involves, and start with the Linux kernel target the project recommends, since that path has the most documentation behind it.

Frequently asked questions

Official sources

1. IntelLabs/kAFL on GitHub
2. License: MIT
3. Project website
4. README
5. Releases