新型“Bad Epoll”0Day漏洞可获取Linux服务器与Android设备的Root权限

好，这篇东西我反复读了几遍，越看越觉得有意思。说实话，这两年Linux内核的漏洞挖得越来越深，但像“Bad Epoll”这种能同时打服务器和Android设备的，确实不多见。尤其是它还是个0Day，而且是从epoll这种我们每天都在用的核心机制里挖出来的——这就很有意思了，值得好好掰扯掰扯。

先快速过一下背景。这个漏洞编号是CVE-2026-46242，名字叫“Bad Epoll”。发现者是Jaeyoung Chung，他把它作为0Day提交给了Google的kernelCTF项目。kernelCTF是啥？就是Google搞的一个内核漏洞悬赏计划，专门收Linux内核的有效利用代码，最低奖金71,337美元——你没看错，七万多美金起步。能拿到这笔钱的漏洞，基本都不是善茬。

这个漏洞的核心问题出在epoll子系统里，具体是ep_remove()这个函数。如果你写过网络相关的服务端程序，epoll你应该不陌生，它是Linux下高性能I/O多路复用的核心机制，几乎所有的网络框架、事件循环、甚至Android的Binder通信都在用。正因为它是内核的“基础设施”，一旦出了问题，波及面就非常广。

漏洞到底出在哪？

我们先从代码层面理解一下。ep_remove()函数的工作是移除一个被epoll监视的文件描述符。它会在file->f_lock这把锁的保护下，清除file->f_ep这个指针。关键问题在于：在执行hlist_del_rcu()（从哈希链表中删除节点）和spin_unlock()（释放锁）的过程中，它还在继续使用临界区内的文件对象。

你可能会想：这不就是常见的“释放后重用”（Use-After-Free, UAF）吗？对，但这次的情况更隐蔽，因为它涉及到一个非常微妙的竞态条件。

具体来说，当另一个线程并发调用__fput()（文件对象的最终释放函数）时，它可能会观察到file->f_ep临时变成了NULL。正常情况下，__fput()应该调用eventpoll_release_file()来通知epoll子系统“这个文件要挂了，你清理一下”。但如果它看到f_ep是NULL，就会跳过这个关键步骤，直接执行f_op->release。结果就是：一个仍然被epoll监视着的eventpoll结构体，被错误地提前释放了。

这就好比你在酒店退房，前台告诉你“你的房间号已经清空了”，但实际上你的行李还在房间里。酒店就把房间重新租给了别人，你的行李（eventpoll结构体）就被别人拿走了。

为什么这么难修？

这里有个更深的坑：struct file采用的是SLAB_TYPESAFE_BY_RCU机制。这个机制的意思是，slab分配器在释放一个对象后，不会立即清空内存，而是允许RCU（Read-Copy-Update）读者在释放后的一小段时间内仍然可以安全地读取该对象。这本身是为了性能优化，但在这里却成了漏洞利用的帮凶。

因为内存槽被释放后，可能被alloc_empty_file()重新分配，用于创建一个新的文件对象。攻击者就可以利用这个时机，对错误的slab缓存触发kmem_cache_free()，造成内核内存的进一步损坏。

更让人头疼的是，这个漏洞的竞态窗口非常窄——只有大约6条指令的宽度。6条指令什么概念？在CPU乱序执行、缓存命中的情况下，可能连一个微秒都不到。但Chung的利用方案通过扩大时间窗口（比如用大量线程同时触发）和崩溃重试机制，在测试目标上达到了约99%的成功率。这已经不是“理论可行”的级别了，而是“拿来就能用”的实战水平。

两个漏洞，一个比一个深

这里还有个有趣的背景故事。2023年，某个内核提交在2500行的epoll代码路径中引入了两个独立的竞态条件。第一个漏洞（CVE-2026-43074）是由Anthropic的AI模型Mythos发现的。你没看错，是AI。这说明前沿AI在发现内核竞态漏洞方面已经展现出了惊人的能力。

但Mythos漏掉了第二个，也就是Bad Epoll。为什么漏了？因为它的时间窗口更窄，而且很难触发内核的主要内存错误检测器KASAN（Kernel Address Sanitizer）。KASAN是内核用来检测内存越界、UAF等问题的利器，但如果漏洞的触发条件太苛刻，KASAN也未必能抓到。这就导致Bad Epoll在运行时几乎不留痕迹，非常难以被发现和调试。

更离谱的是，维护者的第一次补丁尝试没能彻底解决问题。最终修复方案在漏洞披露近两个月后才正式发布。这期间，攻击者如果已经知道了这个漏洞，完全可以在补丁出来之前大肆利用。

攻击流程拆解

Chung的利用方案大致分为几步：

1. 准备四个epoll对象，分成两组。关闭其中一组来触发竞态条件，另一组则成为“受害对象”。
2. 跨缓存攻击：通过精心构造的内存布局，将一个8字节的UAF写入转化为文件对象的UAF。
3. 信息泄露：利用/proc/self/fdinfo获取任意内核内存读取权限。这一步很关键，因为现代内核开启了KASLR（内核地址空间布局随机化），你需要先知道内核代码和数据的内存布局。
4. ROP链劫持：拿到了内核内存的读取权限后，就可以构造面向返回编程（ROP）链，劫持控制流，最终获取root shell。

整个攻击链环环相扣，每一步都需要对内核内存管理、slab分配器、epoll内部数据结构有极其深入的理解。这也是为什么这类漏洞的悬赏金额这么高——能写出来的人，本身就是顶尖的内核安全研究员。

影响面有多大？

前面说了，这个漏洞不仅能打Linux服务器和桌面系统，还能打Android设备。原因很简单：epoll是Linux内核的核心组件，无法被禁用或卸载。相比之下，有些漏洞利用的模块（比如之前提到的“Copy Fail”漏洞）是可选的，Android厂商可以选择不编译或者不加载。但epoll不行，Android的Binder、SurfaceFlinger、甚至应用层的事件循环都依赖它。禁掉epoll，手机基本就废了。

所以，目前没有任何有效的缓解措施。管理员和应用开发者只能等待上游补丁，或者等发行版向后移植修复。对于Android用户来说，这意味着你需要等待手机厂商推送安全更新——而这个周期往往是以月为单位计算的。

我们能学到什么？

从技术角度看，这个漏洞再次提醒我们：并发编程的坑，永远挖不完。即使像epoll这样被广泛使用、经过无数次review的代码，依然能在2500行中藏下两个独立的竞态条件。而且，其中一个还是AI发现的，这说明自动化漏洞挖掘已经进入了“卷”的阶段。

从安全实践的角度看，不要以为“没人会闲着没事挖内核漏洞”。七万美金的悬赏，加上0Day在黑市上的价格，足够让顶尖研究员投入大量精力。对于企业来说，及时更新内核、启用KASAN（虽然性能有损耗）、部署内核热补丁（如kpatch），都是值得考虑的防御措施。

最后，如果你在写内核模块或者驱动，对epoll相关的操作一定要慎之又慎。尤其是涉及到文件对象的生命周期管理、锁的释放顺序、以及RCU的使用，多想想“如果另一个线程同时操作会怎样”。因为现实世界的并发问题，往往不会在你测试的时候出现，只会在生产环境最忙的时候给你致命一击。

---

好了，这篇就聊到这。如果你对epoll的内部实现感兴趣，或者想看看完整的利用代码（等公开后），我后面可以再写一篇更底层的分析。