Apple 这次修的漏洞，官方描述看起来不吓人：应用可能导致系统意外终止。

但研究披露给出的信息更具体。2026 年 5 月 11 日，Apple 在 macOS Tahoe 26.5 中修复 CVE-2026-28952。攻击者如果已经能在本机以非特权用户执行代码，就可能通过公开 syscall，在 Apple Silicon M5 且启用 MIE 的环境里拿到内核提权。

这件事最容易被讲歪。

它不是远程零点击，不是所有 Apple 设备一起中招，也不是 MIE 整套硬件内存保护被打穿。问题更窄，也更值得安全研究员盯住：MIE 把很多风险压到少数可信路径上，而这次出错的，正是那个能改只读内核区域的入口。

MIE 原本防什么：把高价值内核对象锁进 RO zone

MIE 的目标，不是让内核漏洞消失。它做的是另一件事：让传统内存破坏更难变成稳定利用。

大致可以这样理解。普通内核堆由 EMTE 做硬件标签检查；ucred、task_t、AMFI、代码签名状态这类高价值结构，被放进 RO zone；页表变化再由 SPTM 约束。内核权限很高，但也不能随手改这些只读页。

例外是 _zalloc_ro_mut。

它是 MIE 体系里被授权修改 RO zone 的受信任写入口。换句话说，大门加固以后，真正需要反复审计的地方变成了钥匙孔。

位置MIE 的原本防线本次漏洞相关性判断
普通内核堆EMTE 标签检查不是主要突破口传统 UAF/OOB 更难直接变成利用
RO zone只读页保护高价值对象被可信写函数越界写入防线强度集中到入口校验
SPTM约束页表修改未被直接绕过监控机制本身不是失败点
_zalloc_ro_mut合法写 RO zone 的入口target + len 整数回绕小校验承载大边界

研究团队 Calif.io 与 Claude/Anthropic Research 协作发现的问题，就落在这个入口上。

这里也要把边界说死：现有材料指向的是本地提权。没有证据支持把它写成远程攻击，也不能扩大成所有 Apple Silicon 或所有 Apple 设备受影响。

漏洞怎么绕过：target + len 回绕后，可信写入越界了

漏洞核心不玄。

_zalloc_ro_mut 在写入前，需要确认目标地址和长度没有越界。旧逻辑会计算 target + len，再拿结果做范围判断。

问题在于，如果 len 足够大，64 位加法会发生整数回绕。计算出的 end 值可能反而落到比 target 更低的位置。

于是就出现了一个危险错位：检查阶段看到的是“回绕后的 end”，写入阶段执行的却仍是攻击者给出的真实 len。检查放行，memcpy 继续写，合法 slot 外的 RO zone 对象就可能被覆盖。

RO zone 里不是普通缓存。

ucred 记录进程身份。task_t 关联 Mach 任务控制。AMFI 和代码签名状态决定程序能不能执行、以什么权限执行。攻击者如果能把目标进程的 ucred.cr_uid 改成 0，后续内核做权限判断时，这个进程就会被当作 root。

这也是它对不同人群的影响差异。

普通 Mac 用户不需要把它理解成“点开网页就被拿下”。攻击者要先能在本机跑代码，才有机会继续提权。现实动作是检查系统版本，尽快更新到 macOS Tahoe 26.5。

企业安全团队更该紧张一点。本地提权常常不是攻击链第一步，却是沙箱逃逸、权限维持、终端控制的关键拼图。补丁 SLA 不能只盯浏览器、邮件和远程入口，内核本地提权也要进入优先队列。

安全研究员和红队则会盯另一个点：以后类似 _zalloc_ro_mut 的受信任路径，审计价值会变高。硬件防线越强，能合法穿过防线的少数函数越关键。

补丁说明了什么：防守边界被压缩到少数特权路径

研究者对比 26.4.1 与 26.5 后，看到 _zalloc_ro_mut 的关键变化主要有两类。

一类是把溢出检查提前。这样不会再带着已经回绕的地址进入范围判断。

另一类是加入基于 TPIDR_EL1 的 per-CPU 边界校验。它不再只依赖全局 RO zone 范围，而是把检查压到更具体的 CPU 上下文里。

补丁变化修的是什么暴露出的防守边界
提前做溢出检查避免 target + len 回绕后继续通过范围判断地址计算本身就是安全边界
加入基于 TPIDR_EL1 的 per-CPU 边界校验限制跨上下文、跨区域的错误写入全局范围判断不够细

这比“修了一个整数溢出”更有信息量。

MIE 的工程思路是把普通内存破坏的利用难度抬高。这个方向成立。但代价也很清楚：风险会集中到少数拥有特权的写路径上。一旦这些路径放行，硬件保护会把这次写入当成合法动作。

这和 Windows 的 VBS/HVCI、Android 与 Chrome 生态里的 MTE 思路有相通处：都在用硬件或更底层隔离补软件内存安全的短板。Apple 的 RO zone 路线更强调“少数入口、强约束”。这次漏洞说明，这条路线不是没用，而是入口函数必须按安全边界来审，不能只按普通工具函数来审。

接下来真正该看的是三个具体变量。

Apple 会不会继续收紧 _zalloc_ro_mut 这类接口的验证方式。MIE 会不会扩展到更多 Apple Silicon 型号和系统组件。第三方研究团队能不能在真实攻击链中复现类似的受信任路径滥用。

还有两个目前看不清的点，也不该硬编：是否已有在野利用，材料里没有给出确定证据；CVSS 或官方严重性评级，也需要以 Apple 公告和后续披露为准。

回到开头那句“系统意外终止”。如果只看这几个字，很容易低估它。真正的重点不是崩溃，而是一次可信写入口的边界失败，刚好落在 MIE 最敏感的位置上。