BlogEventsIndustry Conference

Exploring Fuzzing for Zephyr Applications with libFuzzer and AFL++

By July 23, 2026No Comments
Fuzzing Zephyr Apps - Struggles of Dynamic Analysis on Embedded Applications - Jayashree Srinivasan, Analog Devices

Open Source Summit North America 2026 and Embedded Linux Conference brought together the open source community in Minneapolis from May 18-20, 2026.

As part of the Zephyr track, Jayashree Srinivasan from Analog Devices presented “Fuzzing Zephyr Apps: Struggles of Dynamic Analysis on Embedded Applications.”

Fuzzing is a runtime testing technique that provides malformed, random, or unexpected inputs to software and monitors it for crashes, memory leaks, or other unexpected behaviour. Unlike static analysis, fuzzing only tests executed code paths, but it usually produces fewer false positives and can uncover issues that appear only under specific runtime conditions.

The session focused on why fuzzing embedded applications is much more difficult than fuzzing general-purpose software. Embedded systems use many different architectures, boards, toolchains, peripherals, and protocols. Inputs may depend on register values, hardware state, sensors, actuators, or specific communication sequences.

Fuzzing Zephyr Apps - Struggles of Dynamic Analysis on Embedded Applications - Jayashree Srinivasan, Analog Devices

Execution is another major challenge. Embedded software is closely tied to hardware, so a fuzzing environment may need to model the processor, memory, interrupts, and peripherals. Instrumented binaries also require more memory and computing resources, which can be difficult on constrained devices.

Crash detection is equally complicated. Embedded applications often run continuously and may stall or halt instead of terminating with a clear error. They are also highly state-dependent, and maintaining register or memory state between test cases can be difficult.

Jayashree reviewed several approaches used by the research community. Hardware-in-the-loop provides the highest fidelity but can be difficult to scale. Full-platform emulation offers a virtual environment but requires significant modelling work. Rehosting provides another option by emulating the processor and replacing hardware interactions with software models.

One example discussed was HALucinator, which replaces Hardware Abstraction Layer functions with higher-level software models or Python handlers. The talk also covered research that fuzzes individual RTOS tasks instead of rehosting the entire system.

Zephyr currently supports fuzzing through libFuzzer, an in-process, coverage-guided fuzzer from the LLVM ecosystem. Developers create a fuzzing harness that passes generated input to the target function, while SanitizerCoverage collects execution information.

libFuzzer is fast and useful for API-level targets, short CI runs, parsers, cryptographic libraries, and network stacks. However, because the fuzzer and target run in the same process, a target crash also terminates the fuzzer. They also share the same memory space.

The session then introduced AFL++, a widely used open source, coverage-guided fuzzer. AFL++ traditionally runs the fuzzer and target in separate processes, providing isolation when the target crashes. It supports both Clang and GCC and includes modes such as persistent mode, QEMU mode, Frida mode, and Unicorn mode.

Jayashree presented early work to integrate AFL++ with Zephyr’s native simulator platform. The Zephyr application is compiled using the AFL++ toolchain, creating an instrumented executable that can be tested with afl-fuzz.

Using this setup, the team was able to detect intentionally injected crashes. AFL++ saved the input that caused the crash, which could then be replayed using GDB to obtain a backtrace.

The current implementation is limited to the native simulator platform. An RFC and pull request have been opened, but the work still requires refactoring before it can be merged.

Possible next steps include extending support to POSIX-based platforms and platforms supported by QEMU, exploring reusable peripheral models, and creating task-specific fuzzing contexts.

The immediate goal is to discuss these ideas with the Zephyr Security Working Group and gather feedback from the wider community.

The session concluded that Zephyr’s current libFuzzer integration is useful for API-level fuzzing, while AFL++ could help support longer fuzzing campaigns and broader application-level testing across Zephyr platforms.

Watch the session here. Check out the OSS NA 2026 playlist here.