2. 栈溢出危害：系统崩溃、程序异常退出、数据损坏、安全漏洞（代码执行）、服务拒绝
好，咱们接着聊。上一节我讲了栈溢出的基本原理，说白了就是往栈里塞了太多东西，把不该碰的地方给踩了。那这一节，咱们得直面一个问题：栈溢出到底能造成多大的破坏？
我见过不少刚入行的朋友，觉得栈溢出就是个“运行时错误”，大不了程序崩了重启一下。嗯，这种想法很危险。你想想看，一个栈溢出，轻则让你的程序默默退出，重则能让整个系统瘫痪，甚至被黑客利用，拿到你服务器的控制权。这不是危言耸听，我在项目中真的遇到过。
咱们把栈溢出的危害拆开来看，主要有五个层面。我习惯用一个表格来总结，这样一目了然：
| 危害类型 | 严重程度 | 典型表现 | 我见过的真实案例 |
|---|---|---|---|
| 系统崩溃 | ★★★★★ | 蓝屏、死机、看门狗复位 | 嵌入式设备在高压测试中频繁重启 |
| 程序异常退出 | ★★★★ | Segmentation fault、Access Violation | 后台服务进程无故消失，日志里只有“Killed” |
| 数据损坏 | ★★★★ | 变量值被篡改、数据库记录错乱 | 金融交易系统出现“幽灵订单”，排查了三天 |
| 安全漏洞（代码执行） | ★★★★★ | 远程控制、提权、植入后门 | 某开源库被爆出缓冲区溢出漏洞，影响数百万设备 |
| 服务拒绝 | ★★★ | 端口无响应、CPU 100%、内存泄漏 | Web服务器被精心构造的请求打挂，业务中断2小时 |
2.1 系统崩溃：最直接的后果
栈溢出最直接的后果，就是系统崩溃。为什么会这样？因为栈里保存着函数的返回地址、局部变量，还有关键的寄存器信息。一旦栈被撑破，这些数据就全乱了。
我举个例子。在嵌入式系统里，栈溢出经常导致硬件异常。比如ARM Cortex-M系列芯片，它有个“硬故障”（HardFault）机制。一旦检测到栈指针跑飞了，CPU会立刻跳转到异常处理函数。如果你的异常处理函数写得不好，或者干脆没写，那系统就直接复位了。
我记得有一次，我在调试一个工业控制器的固件。设备运行几个小时就会莫名其妙地重启。我一开始以为是电源问题，换了电源模块还是不行。后来用JTAG调试器挂上去，盯着栈指针看，发现它在某个递归函数里一路往下掉，最后触发了HardFault。嗯，这就是典型的栈溢出导致系统崩溃。
2.2 程序异常退出：悄无声息的杀手
相比系统崩溃，程序异常退出有时候更让人头疼。因为它可能不会立刻让整个系统挂掉，而是让你的进程默默消失。你排查问题时，翻遍日志可能只看到一行“Segmentation fault (core dumped)”。
说白了，这就是操作系统帮你挡了一刀。当栈溢出导致你访问了非法内存地址时，MMU（内存管理单元）会检测到，然后向进程发送一个SIGSEGV信号。如果进程没有捕获这个信号，默认行为就是终止。
我建议你在开发阶段，一定要开启core dump功能。这样当程序异常退出时，会生成一个core文件。你可以用gdb去分析这个文件，看看程序到底死在了哪一行。我曾经靠这个技巧，在半小时内定位了一个困扰团队两天的栈溢出bug。
ulimit -c unlimited 开启core dump。然后运行程序，崩溃后就会生成core文件。用 gdb ./your_program core 就能进去看现场了。
2.3 数据损坏：最隐蔽的危害
数据损坏，我觉得是栈溢出里最隐蔽、也最危险的一种危害。为什么？因为程序可能不会立刻崩溃，它还能继续运行，但运行的结果全是错的。
你想想看，栈溢出覆盖了某个局部变量。这个变量可能是一个循环计数器、一个状态标志、或者一个指针。一旦它的值被篡改，程序的逻辑就全乱了。比如，一个循环可能多执行了几百次，或者一个if判断永远走错了分支。
我在项目中遇到过一件特别诡异的事。一个交易系统的后台服务，偶尔会生成一些“幽灵订单”——订单金额、数量完全不对，但系统又没有报错。我们查了数据库、查了网络通信，都没发现问题。最后我怀疑是栈溢出，于是在关键函数入口和出口加了栈保护（canary）。果然，canary被触发了。原来是一个字符串拷贝操作，没有检查长度，把相邻的订单结构体给覆盖了。
2.4 安全漏洞（代码执行）：最致命的危害
好，接下来这个，是栈溢出最致命的危害——安全漏洞。说白了，就是黑客可以利用栈溢出，劫持你的程序执行流程，让他自己的代码跑起来。
经典的攻击手法叫“Return-to-libc”或者“ROP（Return-Oriented Programming）”。原理很简单：栈溢出覆盖了函数的返回地址。黑客把这个地址改成他想要执行的代码的地址。比如，他可以改成系统函数 system() 的地址，然后传一个参数 "/bin/sh"。这样一来，你的程序就变成了一个shell，黑客就能远程控制你的服务器了。
我建议你了解一下“栈不可执行（NX）”和“地址空间布局随机化（ASLR）”这两个防护机制。它们能大大增加黑客利用栈溢出的难度。但记住，只是增加难度，不是完全杜绝。道高一尺，魔高一丈。
// 一个经典的栈溢出漏洞示例
#include <stdio.h>
#include <string.h>
void vulnerable_function(char *input) {
char buffer[64];
// 危险！没有检查输入长度
strcpy(buffer, input);
printf("Hello, %s\n", buffer);
}
int main(int argc, char *argv[]) {
if (argc > 1) {
vulnerable_function(argv[1]);
}
return 0;
}strcpy()、sprintf()、gets() 等不检查缓冲区边界的函数。我个人的习惯是，一律用 strncpy()、snprintf() 替代。这不是小题大做，这是血的教训换来的。
2.5 服务拒绝：让业务停摆
最后一个是服务拒绝。这个危害在Web服务和网络应用中特别常见。黑客不需要拿到你的控制权，他只需要让你的服务无法响应正常请求就行了。
怎么做到的呢？很简单，发送一个精心构造的请求，触发你程序里的栈溢出。如果这个溢出导致程序崩溃，而你的进程管理机制（比如supervisor、systemd）会立刻重启它。但黑客可以持续发送这种请求，让你的进程陷入“崩溃-重启-再崩溃-再重启”的死循环。最终，你的服务就彻底不可用了。
我曾经帮一个朋友排查过类似的问题。他们的Web服务器每隔几分钟就挂一次，重启后又正常。一开始以为是内存泄漏，查了几天没结果。后来我抓了网络包，发现有一个特定的HTTP请求，长度特别长，而且包含了很多特殊字符。我让他在本地复现，用gdb一跑，果然，在处理这个请求时，栈溢出了。
好了，这一节的内容就到这里。栈溢出的五种危害，咱们都过了一遍。你想想看，从系统崩溃到安全漏洞，每一个都不是闹着玩的。下一节，我会讲讲如何从根源上预防栈溢出，以及如何用工具快速定位问题。