安卓20条隐形短信就能让手机失联,12和13不会再有补丁

5个字节。

一条短信里只要有这5个字节写得不对，安卓手机的电话功能就会当场崩溃。

正在打的电话会被挂断，打给急救中心的也一样。

你什么都不用点，收件箱里也看不到这条短信。

Android 12到17都在射程内。

打开“设置→关于手机”，找到“安全补丁级别”或“Android安全更新”那一行。

日期是2026-11-01或更晚，就带上了这次的修复；还停在Android 12或13的手机，等不到补丁了。

为什么不是10月，下面会讲到。

5个字节怎么让电话进程崩掉？

5月5日，网名Mark B的研究者（X账号@sourone）把这个问题报给了谷歌的安卓漏洞奖励计划。

出事的地方叫WAP Push。

WAP Push是功能机时代留下来的一种数据短信，运营商用它推彩信通知和网络设置。

手机收到后在后台自己处理，不进收件箱。

安卓处理它的那段代码，第一步是读出消息头有多长。

这个长度用一种可变长的格式写，最多占5个字节，能表示到40多亿。

安卓把读出来的数，直接塞进一个最大只能装21亿多的整数里，中间没有任何检查。

超过21亿的长度一塞进去，就变成了负数。

紧接着，程序按这个长度去申请内存。

要开一块负21亿字节的内存，Java当场报错。

报错没人接住，整个电话进程跟着退出。

一个长度字段被当成负数，问题就这么一句话。

为什么一条短信能折腾一个星期？

单次崩溃不算长，电话进程重启要一两秒，信号格会消失一下。

麻烦在后面。

手机崩溃前没来得及告诉运营商“收到了”，运营商就会按规矩重发。

重发一次，再崩一次。

Mark B在测试里看到，一条短信就能让手机断断续续掉线长达一周。

连发约20条，手机会在很长一段时间里完全用不了。

他在Pixel 9和多款三星Galaxy上试过，次次复现。

澳大利亚、美国、德国、英国的运营商网络，他也都打通了。

更糟的是重启也没用。

这条坏短信会留在手机的待处理队列里，每次开机都拿出来再处理一遍。

GitHub上一位用户贴出了自己Android 12手机的遭遇：大约每90秒重启一次。

安卓的崩溃保护机制最后把手机送进恢复模式，屏幕上只剩“清除数据”的选项。

不想恢复出厂，就得连电脑，用ADB（安卓的开发调试工具）在开机后那几十秒里把那几条记录删掉。

Mark B自己给的土办法是把SIM卡插进一台非安卓手机，让它替你把积压的短信“签收”掉。

他说iPhone根本不理这种消息。

用eSIM的人，连这一招都用不上。

谷歌到底修没修？

修了，只是修的过程有点乱。

Mark B在Hacker News上说，谷歌的初审回复是“临时性拒绝服务不够格”。

工单先被标成不修，又被并到另一张同样没人管的工单里。

可就在6月15日，一位谷歌工程师写好了修复代码，标题就叫“修复decodeWapPdu里的远程拒绝服务”。

这段代码我在安卓开源代码库里打开看了，作者日期确实是6月15日。

安全系统GrapheneOS的团队说，手机厂商7月中旬就通过“安全预览”渠道拿到了这份补丁。

我翻了GrapheneOS的发布记录，从7月29日那一版开始，修复清单里就列着这个漏洞。

到了10月，事情变得拧巴。

谷歌10月5日发布的安卓安全公告，我把每一条拒绝服务漏洞都点开对了一遍。

没有一条指向这次修复，修复代码里的问题编号在整份公告里也搜不到。

可同一个月，Android 14、15、16、17的公开安全代码里都已经带上了这段修复。

追踪安卓补丁的网站Lightrion把它归进了“公告没提到的安全修复”一栏。

GrapheneOS说，它的编号是CVE-2026-58882，评级“严重”，会出现在11月的安全公告里。

11月公告眼下还没发布，这个编号在CVE官方库里我也还查不到。

目前只有GrapheneOS这一个出处。

补丁日期写着2026-10-01，只代表修了10月公告列的那些；这一个不在里面，全看厂商有没有顺手合进去。

一些中文报道写“10月补丁已修复”，这个说法不够准。

谷歌的修法堵住了什么？

Mark B在报告当天就附上了修法：读出长度后先查一下，是负数或者比整条消息还长，就直接丢掉。

谷歌没有这么改。

这次修复动了两处。

第一处，原来只接住“数组越界”这一种报错，现在把所有运行时报错都接住，解析失败就当这条消息作废。

第二处，处理短信时出了任何报错，就把这条消息从待处理队列里删掉，开机反复崩溃的循环就此断开。

那个把长度变成负数的强转，原样留着。

我打开安卓公开主线上的同一个文件看了，第217行的强转还在，捕获范围也没变。

这次修复只进了14到17的安全分支。

效果上，手机不会再崩。

但一个错误的长度仍然会被算出来，只是后面有人兜底。

Mark B在GitHub上对这个修法的评价是：谷歌“（很勉强地）”在上游补了一下。

12和13的手机怎么办？

谷歌的安全公告现在只覆盖Android 14及以上。

12和13已经出了支持期，这次没有它们的份。

这批手机还不少。

我查了统计网站StatCounter今年9月的数据。

它按网页访问量算各版本占比，不等于实际在用的机器数。

全球安卓访问量里，Android 12占7.6%，13占11.6%，加起来接近两成。

中国的数字更高：Android 12一家就占17.45%，排在所有版本第二，12和13合计约四分之一。

国产手机分两种情况。

华为的HarmonyOS NEXT（也就是“纯血鸿蒙”）已经去掉了安卓开源代码，这段Java代码不在里面。

小米、OPPO、vivo、荣耀的系统都建在安卓之上，彩信通知同样靠WAP Push送达。

按常理，这条处理路径还在。

它们有没有自己改过这个文件、10月的更新里带没带这份修复，我没核到，也没查到几家厂商的公开回应。

运营商能不能在网络里把这种畸形短信拦掉？

我没查到任何一家运营商公开说已经在拦，国内三大运营商也没有表态。

反过来，Mark B在四个国家都能把短信送到，说明至少那些网络默认是放行的。

这行代码到底存在了多少年？

我顺着安卓的源码往回翻。

Android 10、11里，这一行一字不差。

一路翻到2010年的Android 2.3，同样的强转已经在那里了，读长度的方式也一样。

可Mark B的页面写的是“从Android 12起复现”，GitHub上那位用户中招的也是12。

11和更早的版本到底会不会崩，没人公开测过。

是后面某个版本改了接住报错的方式，所以老系统反而躲过去了，还是只是没人拿老手机试过？

我对着两个版本的源码比了一阵，没找出答案。