Hybrid Feedback Fuzzing Speeds Up Bug Hunting

Fuzzing is a form of crowd-sourced debugging: a software tester throws random inputs at a program until something breaks, and researchers study the crash to patch the bug. In practice, fuzzing is not a single tool but a family of strategies, each balancing a delicate tension: how to press a program toward a potential fault without getting lost in a forest of harmless paths. A new study from Shandong University and collaborators introduces HF-DGF, a framework that reframes directed grey-box fuzzing by using a trio of feedback signals that steer both the journey to a target and the exploration of the surrounding state space.

HF-DGF, short for Hybrid Feedback Guided Directed Grey-box Fuzzing, blends three feedback streams—control-flow distance, value-flow influence, and slice coverage—into a single, intelligent seed scheduler. The work, led by Guangfa Lyu and Xiaofei Ren at Shandong University’s School of Software (with Zhenzhong Cao of Qufu Normal University and Fengyu Wang at Quan Cheng Laboratory contributing as co-authors), argues that this trio can reframe how fuzzers navigate large, real-world programs. The result is a fuzzing system that reaches a target faster and explores the right parts of a program more effectively, all while trimming unnecessary overhead.

A sharper map to targets

Traditional directed fuzzers lean on a coarse map: they estimate how far a seed’s path is from the target using function-level distances in a call graph. But real software is messy. Indirect calls, inlining, and dense inside-function logic mean that a seed’s true path can diverge long before it reaches the target. HF-DGF replaces this with a basic-block level distance on a virtual interprocedural CFG, computed by a backward-stepping algorithm. In plain terms: you start at the target, walk back through the program’s structure, and tally how many steps you’d need to reach it from any given block.

The paper lays out four steps to this distance calculation. First, it identifies functions that can reach the target by walking the call graph and considering indirect calls. Second, it gauges how deep each call-site block sits inside its function. Third, it computes distances from those call sites to the target using a fixed stepping rule. Fourth, it runs a reverse, block-by-block traversal through each reachable function to assign distances. The result is a finer map for each basic block, not just for each function.

Why it matters: with a finer map, seeds that sit closer to the target in actual execution paths get more attention, reducing wasted mutations on code paths that won’t bring you to the crash site. The authors describe this as a “reach-first, explore-second” philosophy, a departure from the older, more diffuse navigation strategies that often trail far from the goal before discovering a bug.

Exploring the target state space

Reaching a target location is only half the battle. Some vulnerabilities reveal themselves only under particular data states or value patterns that interact with memory, pointers, or complex constraints. HF-DGF tackles this with a value-flow influence score, a measurement of how much a given piece of code can alter the data that matters for the target. The team builds a value-flow graph that encodes def-use chains and pointer relationships, then assigns higher influence to blocks that sit closer to the target and that can swing the relevant data states.

They complement this with slice coverage, a concept borrowed from program slicing: only the parts of the program that can affect the target data are instrumented to report coverage. The final feedback for a seed is a blend of its distance to the target, its accumulated value-flow influence along its path, and how much slice-covered territory it explored. The authors describe this as a multi-dimensional, hybrid signal that nudges fuzzing toward both reaching the target and probing the surrounding state space where many bugs hide—especially those that require a precise data state to trigger.

In effect, HF-DGF treats data-dependency as a living map of influence, not just a destination to reach. It’s like upgrading from a street map to a treasure map: you’re not only told where to go but also which actions along the way are most likely to reveal hidden prizes.

Reducing overhead with selective instrumentation

A practical concern for any system that adds feedback is overhead. Would the richer signals bog down the fuzzing loop? HF-DGF responds with a three-pronged instrumentation strategy. Coverage feedback is gathered only from sliced blocks—the parts of code that matter for the target. Distance feedback comes from boundary blocks—the edge of the sliced region. And value-flow feedback is collected from blocks that carry a value-flow influence toward the target.

The payoff is substantial: selective instrumentation cuts the number of instrumented blocks for coverage feedback by roughly three-quarters and for distance feedback by about the same margin, while still keeping the critical value-flow blocks in the mix. The authors report that only about 0.28% of blocks need value-flow instrumentation, yet those blocks can carry outsized influence on guiding fuzzing toward vulnerable states. The result is a fuzzing loop that remains richly informed but lean enough to be practical for large programs.

To keep the energy budget sane, HF-DGF allocates mutations according to a multi-dimensional recipe. Seeds that are closer to the target, that carry stronger value-flow influence, and that cover more of the sliced territory get more mutations. The team even borrows ideas from simulated annealing to avoid getting stuck in local optima, applying a cooling schedule to both the distance-based and value-flow components. The end product is a fuzzing engine that stays focused on promising seeds without wasting cycles on unproductive branches.

Real-world impact and what it means

To test HF-DGF, the researchers ran 41 vulnerabilities drawn from real-world programs and benchmarks. The results are striking: across a set of 20 benchmarks where all tools produced a median time-to-crash, HF-DGF was roughly 5.05× faster than AFL, 5.79× faster than AFLGo, a staggering 73.75× faster than WindRanger, 2.56× faster than DAFL, and 8.45× faster than Beacon on average. In many cases where other fuzzers struggled to reproduce crashes, HF-DGF pulled ahead decisively.

One counterintuitive finding: HF-DGF often logged lower code coverage even as it found all the targeted vulnerabilities. In other words, the fuzzer didn’t roam the entire codebase, but it hunted the exact corners of state space that mattered for the vulnerabilities at hand. In their top-performing targets, HF-DGF’s coverage was dramatically lower than that of AFL, AFLGo, WindRanger, and DAFL—yet every vulnerability in the test set was triggered. The takeaway is not that coverage is irrelevant, but that targeted, data-driven navigation can trump brute-force exploration when you know where to look.

Beyond crash reproduction, HF-DGF also shines on the static-analysis side. The static analysis phase runs far faster than competing approaches, letting fuzzers start sooner and adapt quickly to code changes. The authors describe the overall system as a pipeline where fast upfront analysis pays dividends during the heavy, embodied testing phase.

Finally, the authors’ ablation studies illuminate how each component contributes to the whole. Removing distance guidance, shackling selective instrumentation, or dropping value-flow feedback all erode performance. The combined system—distance, value-flow influence, and slice coverage, paired with selective instrumentation—outperforms AFLGo, WindRanger, DAFL, and Beacon by a wide margin, sometimes by nearly an order of magnitude in time-to-exposure.

In short, HF-DGF offers a practical blueprint for smarter testing. It doesn’t just push fuzzers to work harder; it teaches them where to push and what to listen for. The study is a collective argument that the next generation of vulnerability hunting will be less about brute force and more about a chorus of signals that guide inputs to the exact spots where bugs live. As software systems continue to grow in scale and complexity, tools like HF-DGF could become essential teammates in the ongoing mission to secure the digital world.

Institutional note: the HF-DGF work originates from Shandong University’s School of Software in Jinan, China, with co-authors from Quan Cheng Laboratory and Qufu Normal University’s School of Cyber Science and Engineering. The study’s lead authors are Guangfa Lyu and Xiaofei Ren, with Zhenzhong Cao and Fengyu Wang contributing as well. The research team’s affiliations and the breadth of real-world benchmarks underscore the collaboration between academia and applied security research in pushing fuzzing forward.