AFL++ 中 fuzzer_stats 状态更新问题的分析与解决

问题背景

在使用 AFL++ 的 QEMU 模式对 c-ares 目标进行模糊测试时，发现 fuzzer_stats 文件中的运行时间(run_time)和最近发现(last_find)字段未能按预期更新。即使在设置了 AFL_FUZZER_STATS_UPDATE_INTERVAL 环境变量后，问题依然存在。

问题现象

1. 运行时间(run_time)字段保持为0，不随实际测试时间增长而更新
2. 最近发现(last_find)字段同样不更新
3. plot_data 文件更新滞后，有时甚至完全没有数据
4. 问题在不同目标测试中重现，非偶发现象

技术分析

可能原因一：文件描述符未正确释放

当通过脚本(如Python)读取 fuzzer_stats 文件时，如果文件描述符未正确释放，可能导致读取到缓存内容而非最新数据。正确的做法应该是：

1. 每次读取都重新打开文件
2. 读取完成后立即关闭文件描述符
3. 避免长时间保持文件打开状态

可能原因二：模糊测试进程性能瓶颈

在以下情况下，状态更新可能会被延迟：

1. 目标程序执行时间过长
2. 使用复杂变异策略(如cmplog)
3. 同步大型目标时的性能开销

这种情况下，模糊测试性能优先于状态更新，属于设计预期行为。

可能原因三：特定模式下的bug

在非标准模式下(如dumb模式或无fork服务器模式)，可能存在状态更新机制的bug。这些模式本身使用场景有限，通常不建议在生产环境中使用。

解决方案

验证步骤

1. 直接通过命令行验证状态更新：

   AFL_FUZZER_STATS_UPDATE_INTERVAL=10 afl-fuzz -i in -o out -Q -- ./target
   

   在另一个终端中：

   while : ; do grep run_time out/default/fuzzer_stats; sleep 10; done
   

2. 确认Python脚本正确释放文件描述符：

   def read_fuzzer_stats():
       with open('out/default/fuzzer_stats', 'r') as f:
           return f.read()
   

最佳实践

1. 对于自动化监控：

   • 每次读取都重新打开文件
   • 设置合理的监控间隔(建议≥30秒)
   • 处理可能的文件读取异常

2. 对于性能敏感场景：

   • 优先使用instrumentation模式而非QEMU模式
   • 简化目标程序环境
   • 监控系统资源使用情况

结论

AFL++ 的状态更新机制在标准使用场景下工作正常，问题多出现在：

1. 文件访问方式不当
2. 特殊运行模式
3. 极端性能场景

通过规范的实现方式和合理的监控策略，可以可靠地获取模糊测试进度数据，用于判断测试是否进入停滞阶段。对于确实存在的bug，建议使用最新dev分支代码并关注相关修复。