Lnav项目中W3C日志格式解析的栈使用后返回问题分析

问题背景

在Lnav日志分析工具的最新开发版本中，发现了一个与W3C日志格式解析相关的内存安全问题。当处理特定格式的日志文件时，程序会出现栈使用后返回(Stack-use-after-return)的错误，这可能导致程序崩溃或不可预测的行为。

问题现象

当使用ASAN(AddressSanitizer)构建的Lnav处理包含特定日期格式的W3C日志时，会触发以下错误：

AddressSanitizer: stack-use-after-return on address 0x7ffff46b73dc

错误发生在tm2sec(tm const*)函数中，该函数用于将tm结构体转换为时间戳。调用链显示问题起源于W3C日志格式解析器中的scan_int方法。

技术分析

根本原因

从调用栈分析，问题发生在处理日志中的日期字段时。当解析器尝试将"2000/80"这样的非法日期转换为时间戳时，程序访问了一个已经返回的栈帧中的数据。具体来说：

1. w3c_log_format::scan_int方法在处理日期字段时调用了exttm::to_timeval()
2. exttm::to_timeval()又调用了tm2sec(tm const*)进行时间转换
3. 此时传入的tm结构体指针指向了一个已经释放的栈内存

代码层面分析

在log_format_impls.cc文件的1375行附近，W3C日志解析器尝试将字符串形式的日期转换为时间值。当遇到非法日期格式(如"2000/80"，2月80日不存在)时，时间转换函数可能使用了无效的临时变量。

解决方案

该问题已在提交2fc1ee4中被修复。修复方案主要涉及：

1. 确保时间转换函数中使用的临时变量有正确的生命周期
2. 增加对非法日期格式的健壮性处理
3. 避免在栈上创建临时对象后传递其指针给可能延迟使用的函数

预防措施

对于类似问题的预防，建议：

1. 在使用ASAN等内存检测工具进行持续集成测试
2. 对于时间解析等关键功能，增加边界条件测试用例
3. 避免在栈上创建对象后传递其指针给可能超出当前作用域的函数
4. 考虑使用智能指针或值传递替代裸指针传递

总结

这个案例展示了日志解析器中常见的一类问题——对输入数据的假设过于乐观。在实际应用中，日志格式和内容可能千变万化，解析器必须具备足够的健壮性来处理各种边界情况。Lnav项目通过及时修复这类问题，进一步提高了其作为专业日志分析工具的可靠性。