Combining LLMs and Fuzzing to Find Memory Bugs

Vulnerability researchers are revolutionizing open-source security by merging coverage-guided fuzzing with Large Language Models (LLMs) to uncover severe memory corruption bugs. This article explores how this hybrid approach works, focusing on how LLMs automate the creation of fuzzing harnesses, generate complex and structure-aware test inputs, and mutate data to bypass roadblocks that stop traditional fuzzers. Finally, it covers how researchers use artificial intelligence to rapidly triage crashes and pinpoint critical vulnerabilities like buffer overflows and use-after-free errors.

Understanding the Core Technologies

Coverage-guided fuzzers—such as AFL++, libFuzzer, and Honggfuzz—work by feeding random or mutated data into a target program while monitoring which lines of code are executed. The goal is to maximize code coverage and trigger edge cases that cause memory corruption, which is detected using tools like AddressSanitizer (ASan). However, traditional fuzzers lack semantic understanding; they rely on brute-force guesswork, often getting stuck on complex input validation.

LLMs excel at pattern recognition, code comprehension, and generating structured text. By integrating LLMs into the fuzzing pipeline, researchers replace blind guesswork with context-aware intelligence.

Automating Fuzz Driver Generation

To fuzz a specific function within an open-source library, a researcher must write a "fuzzing harness" or driver. This small piece of code initializes the software's state and passes the fuzzer's input to the target API. Writing harnesses manually is time-consuming and requires deep knowledge of the target codebase.

Researchers now use LLMs to automate this step. By feeding the target library’s header files, API documentation, and existing unit tests into an LLM, the model can automatically write hundreds of valid C or C++ fuzzing harnesses. The LLM understands how functions are meant to be chained together, ensuring the fuzzer tests realistic program states rather than triggering false-positive crashes caused by improper API usage.

Generating Structure-Aware Seed Inputs

Fuzzers perform significantly better when given an initial "corpus" of valid sample inputs, known as seeds. If a target program expects a complex file format, a network protocol packet, or a specific SQL query, a traditional fuzzer may spend days just trying to guess the correct syntax before reaching the deeper, vulnerable logic.

LLMs already possess vast knowledge of file formats, protocols, and programming languages. Researchers prompt LLMs to generate a diverse set of valid, edge-case seed inputs tailored to the target software. Furthermore, instead of mutating raw bytes at random, LLMs are used as structure-aware mutators. They alter inputs while preserving the mandatory syntax rules, allowing the fuzzer to penetrate deep into the application's core logic where hidden memory corruption bugs reside.

Overcoming Fuzzing Roadblocks

During a campaign, a coverage-guided fuzzer will inevitably hit a "coverage plateau," meaning it can no longer find new paths in the code. This usually happens when the fuzzer encounters complex conditional statements, checksums, or specific state requirements that random mutations cannot satisfy.

When a fuzzer stalls, automated scripts extract the exact source code of the blocking condition and send it to an LLM. The researcher's pipeline asks the LLM to analyze the code and generate an specific input that satisfies the condition. Once the LLM provides the solution, the input is added to the fuzzer's queue. The fuzzer breaks through the roadblock and continues exploring previously unreachable code paths, exposing new attack surfaces to memory corruption checks.

Automated Crash Triage and Root Cause Analysis

A successful fuzzing campaign can generate thousands of crashes, many of which are duplicates or non-exploitable bugs. Analyzing stack traces and memory dumps to find the root cause of a memory corruption bug—such as a heap buffer overflow, integer overflow, or use-after-free vulnerability—is a major bottleneck for researchers.

LLMs streamline this triage process. Researchers feed the sanitizer crash reports, stack traces, and the corresponding source code files into the LLM. The AI analyzes the execution flow, explains the exact mechanism of the memory corruption, and assesses the potential severity of the bug. This allows vulnerability researchers to quickly filter out noise, prioritize critical vulnerabilities, and even generate proof-of-concept exploits and patches for the open-source maintainers.