今天（10月1日）知乎上挂出一篇《CVE-2026-43074：Linux内核eventpoll竞态漏洞深度解析》，不少做底层和服务器方向的开发者才反应过来：七月以来圈里传的"epoll高危漏洞"，掰开其实是两个。CVE-2026-46242，大名BadEpoll；CVE-2026-43074，是跟它共用一个CVSS 7.8、同一个子系统、同一个月修复、甚至大概出自同一段代码区域的"双胞胎"。这篇新解析里最劲爆的故事线我们放在后面讲——先把今天真能用的部分盘完。知乎
一、时间线对齐：为什么这两个CVE会被混
把两条线并排放在一起，混淆的原因一目了然：
2026年4月2日：43074的上游补丁合入主线，标题是 “eventpoll: defer struct eventpoll free to RCU grace period”，把 `kfree(ep)` 改成 `kfree_rcu(ep, rcu)`。知乎
2026年4月底：BadEpoll（46242）的修复代码合入内核主线。微博
2026年7月5日：The Hacker News 对外披露 BadEpoll：首尔大学计算机安全实验室研究员 Jaeyoung Chung 在上半年发现并命名，CVSS 7.8、本地提权，Linux 桌面、服务器和谷歌安卓均受影响，普通用户进程可提权到 root。知乎同日出现对应提问，话题挂"Linux内核/安卓系统漏洞"。微博
2026年10月1日：43074 才第一次在中文圈有了命名解析文章——而它其实是两个漏洞里先被修的那个。
也就是说：46242 的公开命名比修复晚了近三个月，43074 的公开命名比修复晚了整整六个月。你的机器大概率早就打过补丁了——但"打过"和"生效"是两回事，这是整个事件里最容易误判的一环，第五节展开。
二、两个漏洞分别是什么：一个讲透了，一个只有名字
43074 这次被讲得很干净，值得转述给同样只看过标题的人：它出在两个线程同时关闭相互监控的 epoll 实例的竞态上。线程A从epoll实例A的监视列表里移除实例B，清除 `file->f_ep` 字段、向其他线程宣告"这个文件不再被监控了"，但清理没做完；线程B同时在关闭B，看到 `f_ep` 已清，误判A那边清理完毕，跳过关键步骤直接释放了B对应的对象内存；线程A还当对象活着，继续往已释放的内存里写——教科书级的 Use-After-Free。技术本质就一句话："移除对象"和"释放对象"不是原子操作，并发场景下留出了一个可被利用的空窗期。修复也用了内核最标准的手法：RCU宽限期延迟释放，确保所有读者越过读端临界区再真正回收。知乎
BadEpoll 这边，目前公开材料的口径只有"epoll子系统中的竞争条件导致UAF、可本地提权至root"，机制细节比43074少得多。这是个值得记住的坑：有名字的漏洞不等于有公开分析的漏洞。你要是想判断自己的代码路径（比如自研的网关、事件循环框架里嵌套epoll的用法）到底碰不碰得到46242，现阶段没有足够材料，别硬拍板。微博
三、“AI抓到一个、漏掉另一个”：当假说听，别当结论用
这篇深度解析里传播性最强的论点是：Anthropic 的安全模型 Mythos 审计了 eventpoll 那段约2500行的代码，抓出了43074，却"顺手放过"了同区域另一个竞态——后来被人类研究员找出来、命名成 BadEpoll 的那个。按文章的说法，这划出了AI代码审计的能力边界：面对极窄时间窗口的竞态条件，AI存在系统性盲点。知乎
必须把证据等级说清楚：这条故事线目前只见于这一篇中文解析文章，我在能查到的范围内没有找到第二个独立信源，Anthropic 也未见公开确认这次审计。所以它只能按"待验证假说"处理。但"AI 审计内核"这件事本身已经不需要假说来撑场子——九月的公开信源里至少有三块硬料：TencentOS 安全团队的 Corvus AI 在 9 月披露，一条普通漏洞情报进响应队列后，它 24 小时内揪出了 3 个从未公开的内核漏洞，其中一个拿到了编号 CVE-2026-80530。按内核维护者 Greg Kroah-Hartman 制作的幻灯片，Linux 7.x 系列的 CVE 数量已从 7.1 的逾千涨到 7.2 的逾 1500；网络子系统维护者 Jakub Kicinski 公开说社区"有点不堪重负"，7.3 干脆移除了大量旧 SGI/IBM 驱动来缩小被扫出 bug 的面积。TencentOS 还给了一个量化口径：2026 年 7 月合入主线的补丁里，12.29% 带有 AI 辅助痕迹，较 1 月增长约 13 倍。知乎知乎
再往前数，今年 3 月的 [un]prompted 大会上，顶级安全研究员 Nicholas Carlini 现场演示用 Claude 从 Linux 内核里挖漏洞，这个 bug 早在 2003 年就存在于内核中，直到今天才被 AI 揪出。微博微博
所以这件事的可信度结构是：AI 扫内核、AI 找提权、AI 参与补丁——全是坐实的趋势；唯一没坐实的，是"epoll 这一单具体是 Mythos 接的"。对一个正在纠结"AI 审过的代码能不能少一轮人审"的团队，去掉 AI 这条线下面的事实层依然站得住：同一段约 2500 行的并发敏感代码里，确实先后躺着两个 CVSS 7.8 的 UAF。单轮审计，不管审计员是人还是模型，都不是安全边界。
四、谁真正暴露：按"攻击者能不能进来跑代码"排
先说前提：这是本地提权，攻击者必须先有一个能在你机器上执行代码的落脚点——远程直接打不穿。但有两个事实让影响面比一般 LPE 大得多：epoll 关不掉，任何通用发行版 `CONFIG_EPOLL` 默认开启，没有模块可以禁用；服务器代码几乎全部压在它上面，只要跑网络I/O就在受影响面内。按落脚点风险给运维排个序：知乎
多租户 CI runner 和 K8s 节点——任意构建脚本、任意不可信容器进得来，容器共享宿主内核，容器打补丁没用，要看宿主；
开放执行权限的 VPS、堡垒机——每个登录用户都是潜在落脚点；
开发者工作站——提权成功意味着机器上的云凭据、SSH私钥整包暴露；
安卓设备——内核一样带着epoll，但OEM推送节奏没有统一答案，旧设备是长尾。
对照样本就在同一个月：9 月知乎公开的 RDS 零拷贝本地提权 CVE-2026-43502（ZcopyReaper），出问题的代码从 4.17 就被引入主线，360 的漏洞挖掘智能体已经成功复现，复现文带着完整原理一起挂了出来——从本地提权落脚到打穿内核内存再到 root，这条链从披露到可复现的距离就是这么短。利用现状的口径也统一一下：43074 目前没有已知的公开利用代码；BadEpoll 的 PoC 发布状态，现有材料里查不到，只能说"未见公开"。但"没有 exploit"这个安全感的保质期，看看九月的行业数字就知道有多短：Zero Day Clock 统计显示，2026 年已知高危漏洞中 68% 在公开当日或更早已经出现利用痕迹；Microsoft 的 MDASH 系统平均 21 分钟就能把一份内核漏洞报告转成 PoC，Mythos Preview 模型更是被 TencentOS 披露可在 12 小时内为 8 个 N-day 漏洞生成真实可用的 EXP。从 7 月披露到现在三个月，"风险随公开度上升"不是修辞，是这些机构在批量做的事——只是强度只能说到这，目前还没有已验证的在野利用报道。知乎知乎
五、今天就能做完的自查：重点不是打补丁，是"生效确认"
补丁四五月就进了主线，现在的问题清单是"谁还没吃到"：
看运行内核，别看包管理器：`uname -a` 打印出来的那个版本串才作数。升级了内核但没重启的机器，跑的还是旧镜像——`uptime -s` 对照发行版公告里修复构建的时间，比它早就白升。
拿两个编号分别对公告：在你发行版的安全公告页同时搜 `CVE-2026-43074` 和 `CVE-2026-46242`——两个都要有修复记录才算完，中文社区目前还经常只讨论后一个。
容器和虚拟化场景看宿主：K8s 集群逐节点确认宿主内核版本与重启记录；确实排不出重启窗口的，看你的发行版有没有内核热补丁方案（livepatch/kpatch 类），有就纳入，没有就把重启窗口排进日历。
安卓看补丁级别：安全补丁级别早于2026年5月的设备基本免谈修复；晚于5月的，级别本身证明不了这个CVE被OEM回合过，家庭里的长尾旧设备按"未修复"处理更稳妥。
CI 补一道减害：runner 侧限制非特权用户命名空间这类常规收敛手段，能压缩落脚点，但属于缓解不是修复，别把它当已修。
对了，别把排重启窗口只当成给运维添堵。今年 8 月小红书那条《Linux 7.3 带上了我的 24 个 Patch》拿了 358 个赞——BPF 方向的贡献者晒的，正是从 7.2 的 20 个到 7.3 的 24 个补丁的合入清单。上游补丁合入的节奏和你机器的重启节奏，本来就是同一件事的两端：那些 patch 的价值，要等你把内核版本推上去才开始兑现。小红书
继续盯三个信号：BadEpoll 的机制细节和 PoC 是否随会议公开（发现者后续披露才是真正改变风险曲线的事件）；43074 的 CVE 记录和发行版公告是否开始与 46242 互相引用（现在是各讲各的，混淆还会继续）；Anthropic 是否确认 epoll 审计事件——如果坐实，"AI审计漏报"会成为这轮内核AI化争论里最常被引用的判例，届时该重估的就是你们代码审查流程里"AI过了就免人审"的环节。
一句话收口：epoll 这两兄弟的 CVSS 都是 7.8，修复都在4月，但这两个月里真正值得底层开发者重算的不是分数，是你那台"升了没重启"的机器和那条"AI审过就放行"的流程。
