5 个字节远程打崩安卓电话,谷歌的答复是不修

一条 8 字节的数据短信发到一台 Pixel 9，收件箱里空空如也，通知栏同样安静，发件人号码也没有。正在进行的通话在这条短信落地的一瞬间断开，断开原因记录为 CS_DEATH，电话进程当场死掉。测试机还包括多款三星 Galaxy 和 A 系列机型，复现率 100%。发现者把完整细节交给谷歌，得到的归类是 Non-Security Issue，处理意见一栏写着 Won't Fix。这条短信怎么把电话进程打死、为什么十几年前的修复只补了一半、被拒之后研究者怎么走完披露，下面从头捋。

先看这条短信走的是哪条路。WAP Push 是一种数据短信，走 2948 端口，由系统进程 com.android.phone 里的 WapPushOverSms 组件直接解析，从头到尾不经过用户看得见的任何界面。这个组件在 frameworks/opt/telephony 里，收到消息后调用 decodeWapPdu() 读消息头，头部长度按 uintvar 编码读出来（人话：一种可变长度的整数编码，最多 5 个字节表达一个很大的数），返回值是 long 类型，代码接着把它强转成 int，再拿这个 int 去分配一个字节数组。WapPushOverSms.java 第 217 行读长度，第 244 行拿长度建数组，中间没有任何范围检查。

攻击的全部载荷是 5 个字节：88 80 80 80 00。按 uintvar 规则解码，这 5 个字节等于 0x80000000；强转成有符号 32 位 int，结果变成 -2147483648。接下来这一行代码要求 Java 分配一个负数长度的数组，虚拟机当场抛出 NegativeArraySizeException。异常发生在 telephony 主线程上，没有任何人捕获它，com.android.phone 整个进程被杀，正在通话的线路跟着断掉。攻击者需要的全部信息是对方的手机号，受害者这边没有任何可感知的东西，不点、不开、不装任何东西。

这个文件的历史比漏洞本身更有意思。2013 年 12 月，谷歌工程师 Jake Hamby 改过同一个 WapPushOverSms，commit 标题里明确写着 DoS，目的是防止畸形 WAP Push 让手机陷入重启循环。那次修复捕获的异常类型是 ArrayIndexOutOfBoundsException，防住了越界，没防住负数长度。同样的解析路径，换一种异常就穿透，一穿就是 13 年。这个"SMS of Death"的名字也不是新造的：2011 年 USENIX Security 会议上，Mulliner、Golde 和 Seifert 三位研究者用同名论文演示过对功能机的短信攻击，一条恶意短信远程打崩整台手机，今天这篇算是以智能手机的方式接了当年的题。

单条短信的效果是 1 到 2 秒的服务中断，进程重启后电话恢复。头号放大器在运营商那一侧：手机因为崩溃，从来没有正常确认收到这条数据短信，运营商按重发策略一遍一遍投递，手机一遍一遍崩溃。研究者的测试里，一条消息让手机间歇性掉线断断续续拖了最长一周。这种"受害状态自己给自己续期"的结构，是这条攻击链里最不讲道理的一环。

把伤害升级到持久档需要的是数量和速度。大约 20 到 30 条消息快速连续发送，崩溃和短信数据库的写入操作交错发生，触发竞态条件，存短信的 SQLite 数据库被写坏。数据库一坏，com.android.phone 每次开机读库就崩，电话服务从此起不来，重启治不了，恢复出厂设置也只能顶一阵，因为运营商还在重发那条没人确认的消息，崩完接着崩。完整的恢复路径是先把物理 SIM 卡插到一台非安卓设备上（比如 iPhone），让运营商停止重发，再用 ADB 清掉损坏的短信记录。用 eSIM 的设备连拔卡这个动作也不存在，普通用户基本走不完这条恢复流程。

影响最深的一层不是通话，是紧急呼叫。设备处于攻击中或者数据库已经损坏时，拨打紧急号码没法保证接通，而攻击只需要一个手机号，全程无声。澳大利亚把紧急呼叫能力写进强制监管：按照 Telecommunications (Emergency Call Service) Determination，运营商必须识别无法接通 Triple Zero 的手机，协助用户换机，最终停止向该设备提供服务，Telstra 的公开口径是通知用户后 28 天内屏蔽。2024 年 3G 退网后这套规则又收紧了一轮，原因正是当时出现过能打普通电话、打不通紧急号码的设备。这个缺陷可以按需、远程、无声地制造同样的状态，监管框架为保护公共安全而设，在这里反而成了把伤害再放大一轮的机制。

回到那句 Won't Fix。研究者 Mark Blaszczyk 在 2026 年 5 月 5 日通过 Android & Devices VRP 上报，同一天附上了修复建议，改动是在强转之前加一道范围检查：原始值读成 long，小于 0 或者超过 PDU 实际长度就按通用错误处理，直接返回。一行判断的事。此后的流程是三个工单、四名工程师、多次申诉，谷歌的结论维持不变：未达到严重性阈值，归为非安全问题。90 天协调披露期走完后，细节在 10 月 29 日公开，概念验证应用和完整源码放在 GitHub 上，Apache 2.0 许可，攻击应用只需要一台 Android 11 以上、插着 SIM 卡、有短信发送权限的手机。CVE 编号没有分配。

这条披露留给大家的作业，按现有素材能列出来的有这几条：运营商侧对异常 WAP Push 做过滤是公开信息里唯一提到的缓解路径，尚无大规模部署的实例；企业终端管理可以把"紧急呼叫可拨通"纳入设备健康检查，这项检查在受影响机型上会稳定失败；用户个人在厂商修复之前，从系统层面没有可靠的规避手段，这不是某个 App 的设置能挡住的东西，缺陷在系统进程解析短信的第一现场。

收尾说回那句值得多想一会儿的判断。保密性没有被突破，数据一条没偷；完整性没有被破坏，代码一行没改；被远程打穿的只有可用性，而谷歌的严重性阈值没有把它接住。13 年前那个 commit 的标题里白纸黑字写着 DoS，13 年后同样的文件、同样的解析路径、同类的故事换了一种异常继续成立。一条短信能让一部手机在一周里反复掉线、能让紧急电话按需失联的系统，处理意见写的是不修，这个处理结果本身，比那 5 个字节更值得从业者记住。

主页右上角加星标，陪大家学习新知识。

参考来源：

• 披露站：https://smsofdeath.com
• PoC 仓库：https://github.com/MarkBlah/smsofdeath
• 2013 年 Jake Hamby 的 commit：https://android.googlesource.com/platform/frameworks/opt/telephony/+/567ea11
• USENIX Security 2011 论文：https://dl.acm.org/doi/10.5555/2028067.2028091
• CyberInsider：https://cyberinsider.com/android-sms-telephony-crash-vulnerability