2026 年 7 月 13 日，Nebula Security 公开了一个编号 CVE-2026-43499 的 Linux 内核漏洞。名字叫 GhostLock。影响范围：自 2011 年以来每一个主流 Linux 发行版。严重程度：无权限用户可直接提权至 root，并逃逸容器。发现时间：2026 年。存在时间：15 年。
一个 15 年前写错的函数
所有 Linux 服务器、Android 手机、云容器、嵌入式设备——只要跑着 2011 年之后的内核，都在这条漏洞的射程内。
漏洞出在 kernel/locking/rtmutex.c 里一个叫 remove_waiter() 的函数。这个函数的作用很简单：当一个线程不再等待某个锁时，清理掉它的等待记录。
问题在于，当初写这个函数的人，假设了一个场景——「清理当前线程自己的等待记录」。所以函数里直接写了 current->pi_blocked_on = NULL，这里的 current 就是「正在运行的线程」。
这个假设在 2011 年是正确的。
2011 年之后，内核引入了一个叫 Requeue-PI 的机制，允许一个线程替另一个线程做锁的代理操作。remove_waiter() 被复用了，但调用它的代码传递的 waiter 对象属于另一个正在睡眠的线程。current 不再是「等待者」，而是「代理者」。
函数依然兢兢业业地清除了 current->pi_blocked_on，但真正需要被清理的那个睡眠线程，它的 pi_blocked_on 指针依然挂在那里——指向自己栈上已经被释放的内存。
一个悬空的指针，留在内核里 15 年，没人发现。
不是「难以触发」，是「没人往那想」
这类漏洞有一个专业名称：Use-After-Free（释放后使用）。但 GhostLock 的特殊之处在于，被释放的对象不是堆内存，而是内核栈空间。
栈空间在函数返回后自动「释放」，新的函数调用会复用同一块栈内存。攻击者需要做到三件事：
- 1. 拿到这个悬空指针——利用正常的线程操作就能触发，无需任何特殊权限
- 2. 在栈上布置可控数据——找一个系统调用，让它在正确的栈深度写入攻击者控制的内容
- 3. 触发指针解引用——通过 PI 锁的链式遍历，让内核跟着这个伪造的指针走
Nebula Security 的团队做到了。他们的 exploit 在标准 x86 Linux 系统上的稳定率达到 97%。不仅能从普通用户提权到 root，还能从 Docker 容器逃逸到宿主机。
Google 为这个漏洞的利用演示支付了 92,337 美元 的奖励。这个数字很说明问题——不是因为它高，而是因为它恰好证明了：一个无特殊权限的攻击者，可以稳定地攻陷任何一台未修补的 Linux 机器。
这事最可怕的地方在哪？
不是漏洞本身有多复杂，而是它暴露了开源安全模型的一个结构性盲区。
「足够多的眼睛，可以让所有 bug 变浅」——这是 Linus 定律，开源世界最核心的信条之一。但 GhostLock 用 15 年的沉默给出了一个反例。
remove_waiter() 在被复用之前，逻辑是完全正确的。代码审查不会发现问题，因为问题不在代码本身，而在代码被用在了设计时没考虑的场景里。这种「语义鸿沟」——函数的功能正确但上下文错误——恰好是静态分析和人工审查都容易漏掉的类型。
更麻烦的是，它避开了 lockdep 的检测。lockdep 会检查锁是否被正确持有，但不会检查「谁的锁被持有了」。函数锁住了 current->pi_lock，lockdep 认为一切正常。但这个 current 根本不是应该被操作的那个线程。
15 年间，无数内核开发者 review 过这段代码，无数安全研究员扫描过这个区域。没有人发现问题。不是不够努力，而是这类漏洞天然难以被自动化工具发现，也难以被人工审查捕捉——除非你恰好意识到「这个调用路径是代理路径，不是自阻塞路径」。
给所有跑 Linux 的人一个提醒
补丁已经合入 Linux 7.1（2026 年 4 月）。修复只改了一行：把 current->pi_blocked_on = NULL 改成 waiter->task->pi_blocked_on = NULL。一行代码，15 年的漏洞。
但修复本身不是重点。重点是：你的内核升级了吗？
我翻了一下主流发行版的跟进情况：
- • Ubuntu 24.04 LTS：已在 6 月安全更新中合入补丁
- • RHEL 9 / CentOS Stream 9：补丁在 7 月初的更新中
- • Android 通用内核：已合入，但各厂商的定制内核进度未知
要是你在跑任何面向公网的 Linux 服务——尤其是容器化环境——检查一下内核版本。受影响的内核范围是 v2.6.39-rc1 到 v7.1-rc1，也就是说绝大部分仍在服役的生产环境都在射程内。CONFIG_FUTEX_PI=y 是唯一的前置条件，而大多数发行版默认开启了这个配置。
更深层的问题
这些年安全界的注意力高度集中在几个方向：AI 模型的安全性、供应链攻击、Web 漏洞。内核安全反而成了一个「传统话题」，关注度在下降。但 GhostLock 提醒我们，整个数字世界的底层是 Linux 内核。云服务器跑在 Linux 上，容器跑在 Linux 上，Android 跑在 Linux 上，绝大多数 AI 训练集群也跑在 Linux 上。内核只要有一个这样的漏洞，上层的一切安全防御都形同虚设。
更值得警惕的是，GhostLock 不太可能是唯一一个。2011 年到 2026 年，代码复用、函数被用于非预期场景的事情每天都在发生。这类「上下文错误」的漏洞，可能还有不少潜伏在内核的各个角落里。它们不会自己跳出来，只会等到某个安全研究员恰好走对了那条调用路径。
要说 GhostLock 能带来什么改变，我希望是两点：第一，内核开发者需要建立更严格的「函数契约」检查——一个函数被设计为「只能由调用者自身使用」，当它被复用于代理路径时，编译器或分析工具应该能发出警告。第二，每个跑 Linux 的人，都应该把内核升级放到比应用升级更高的优先级。
毕竟，地基裂了，墙刷得再漂亮也没用。
