AFL++ 项目中 fuzzer 异常终止问题分析

问题现象

在 AFL++ 项目中，一个针对 OpenSSL cmp 模块的模糊测试进程突然终止。通过日志分析发现，该 fuzzer 在运行约 4 天 19 小时后停止工作，最终生成的日志文件大小接近 2GB（2,068,420,061 字节）。错误信息显示，问题发生在读取 AFL++ 工具时出现异常。

技术背景

AFL++ 是一个先进的模糊测试工具，它通过插桩技术监控目标程序的执行路径。在 fork server 模式下运行时，AFL++ 会通过管道与目标程序通信。当这个通信管道异常断开时，通常意味着模糊测试进程本身出现了问题。

根本原因分析

通过深入分析，我们发现问题的根源在于：

1. 内存耗尽：系统配置的 tmpfs 大小为 32GB（33554432k），但模糊测试过程中可能消耗了大量内存资源，导致系统触发 OOM（Out Of Memory）机制终止了进程。

2. 管道通信中断：当 AFL++ 主进程被系统终止时，它与目标程序之间的通信管道会断开。此时目标程序中负责与 AFL++ 通信的代码会检测到这个异常，并输出相应的错误信息后退出。

技术细节

在 AFL++ 的 instrumentation 代码中，存在一个关键的错误处理逻辑：

if (read(FORKSRV_FD, &was_killed, 4) != 4) {
    write_error("read from AFL++ tool");
    _exit(1);
}

这段代码负责从 AFL++ 工具读取数据。当读取失败时（返回值不等于4），会记录错误并退出。这种情况通常发生在：

• AFL++ 主进程异常终止
• 系统资源耗尽
• 文件描述符被意外关闭

解决方案与最佳实践

针对此类问题，我们建议采取以下措施：

1. 资源监控：在长时间运行的模糊测试任务中，应该设置资源监控机制，特别是内存使用情况。

2. 日志轮转：配置日志轮转策略，避免单个日志文件过大影响系统性能。

3. 测试环境优化：

   • 增加 tmpfs 大小或使用持久化存储
   • 设置合理的 memory limit
   • 考虑使用 cgroups 限制资源使用

4. 错误处理增强：在自定义的模糊测试脚本中，可以增加对 AFL++ 进程状态的监控，及时发现并处理异常情况。

经验总结

模糊测试特别是长时间运行的测试任务，需要特别注意系统资源管理。在实际应用中，建议：

1. 定期检查测试进程状态
2. 设置合理的资源限制
3. 实现自动化监控和告警机制
4. 对于关键测试任务，考虑实现断点续测功能

通过以上措施，可以有效减少类似问题的发生，提高模糊测试的稳定性和效率。