分享一个最近遇到的栈溢出的经典例子。
1. 问题现象
某个状态码从正常的0x01突然变了。
核心代码简化后如下：
两次打印之间只调用了read_data()，没有任何代码修改status，但它就是变了。某个情况下read_data读到了24个字节的数据，但是缓冲区只给了16个字节，溢出了，溢出的字节覆盖了status。
这种栈溢出篡改数据的问题，在定位到的时候觉得很简单。但是实际这种情况，并且是偶现问题，而且代码不像是上面这个简化代码这么简单，问题代码藏在一堆代码之间，排查起来还是挺费时间的。
2. 原因分析
为了理解为何status会被改，我们需要看清函数栈帧的内存布局：
栈向下增长，局部变量按声明顺序从高地址向低地址分配。strcpy写入24字节到16字节的buffer时，多出的8字节会向上溢出，覆盖相邻的内存区域。
注意：
同一函数内局部变量的布局，由编译器决定，不一定按声明顺序。即首先声明的变量不一定是存放在高地址。 栈的生长方向不能改变，这是由 CPU 架构决定。
测试代码：
运行结果：
status的地址0x7ffc8b2a3c4f正好在buffer地址0x7ffc8b2a3c40之后15字节处（0x40 + 0x0f = 0x4f）。
解决方案：用安全版本的字符串函数。
2.1 为什么栈会溢出？
C语言的strcpy、sprintf等函数不做边界检查。当源数据大于目标缓冲区时，多余数据会继续写入相邻内存。
栈上相邻的可能是：
其他局部变量（本案例） 函数返回地址（更危险，会导致程序崩溃或被利用） 栈帧指针（EBP/RBP）
2.2 编译器选项增强检测
现代编译器（GCC 7+）有栈保护机制（Stack Canary），但默认只保护返回地址，不保护局部变量之间的溢出。可以通过编译选项增强检测：
# 栈保护（检测返回地址破坏）
gcc -fstack-protector-all -otesttest.c
# AddressSanitizer（检测所有内存越界）
gcc -fsanitize=address -g -otesttest.c
使用 AddressSanitizer 重新编译运行，立即得到精确报错：
=================================================================
==12345==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc8b2a3c50
WRITE of size 24 at 0x7ffc8b2a3c40 thread T0
#0 0x... in strcpy
#1 0x... in read_data test.c:6
#2 0x... in data_process test.c:15
3. 栈溢出预防措施
3.1 代码规范
禁止使用的危险函数
| 危险函数 | 安全替代 | 原因 |
|---|---|---|
strcpy | strncpy/strlcpy | 无边界检查 |
sprintf | snprintf | 无边界检查 |
gets | fgets | 无法限制长度 |
scanf("%s") | scanf("%Ns") | 无边界检查 |
3.2 工具
静态分析：
# Cppcheck
cppcheck --enable=all --error-exitcode=1 src/
# Clang Static Analyzer
scan-build make动态检测：测试环境默认开启
# Valgrind内存检测
valgrind --leak-check=full ./test
# AddressSanitizer
ASAN_OPTIONS=detect_stack_use_after_return=1 ./test
相关文章：
嵌入式开发调试利器 | Sanitizer检测器
工具 | Valgrind仿真调试工具的使用
推荐一个好用的嵌入式静态代码扫描工具！
总结
永远不要相信输入数据的长度，即使是"可信"的传感器数据。
编译器不会完全保护你，需要主动启用检测工具。
栈溢出是最常见的内存错误，但只要建立起"缓冲区必须传大小"的编码习惯，90%的问题都可以避免。
如果这篇文章对你有帮助，欢迎转发。欢迎分享你的踩坑经历。
