CVE-2026-43499（ghostlock）的武器化研究。
这是 rtmutex remove_water() 代理路径中的一个 bug，它会导致任务的 pi_blocked_on 悬空并指向其自身已弹出的内核栈帧。
该 bug 类别和原始利用策略归功于 nebusec（他们的文章在此）
本仓库中的所有内容都是我针对各发行版自行完成的工作：
每个内核家族都需要截然不同的原语，这正是其有趣之处。
Ghostlock 的触发完全无需特权（三个 futex、两个线程，且无需命名空间）。 将悬空指针转化为 root 的过程才是各发行版分道扬镳之处，这取决于帧几何结构、缓解措施以及“在内核已知地址处拥有受控字节”的含义——所有这些都各不相同。 本仓库将按目标家族收集利用链。
| 目标 | 利用链 | 暂存阶段 | 状态 |
|---|---|---|---|
RHEL/CentOS 7 — 3.10.0-1160.102.1.el7 | el7/ — physmap 别名页 + auxv 绘制器 + sched_setscheduler 遍历 | 命名空间内 root（特权容器） | 可用，在全新启动上通过 40/40 压力测试 |
RHEL/CentOS 7 — 3.10.0-693.el7 | 相同利用链，已测量帧几何结构 | 相同 | 组件已验证 10/10；仅待压力测试 |
请参阅每个子目录中的 WRITEUP.md，了解完整的技术分析、根本原因、为何 6.x 时代的现成利用链无法移植、原语发现、我另行构建的内容、实测帧几何结构以及可靠性相关数据。
难点在于——遍历会验证伪造的 waiter 的 ->lock 是否与其找到的锁匹配（3.10 上的 BUG_ON(w->lock != lock)），因此你需要在内核可寻址内存中、且在你已知的地址处放置伪造结构。这正是各内核之间差异巨大的地方（nebusec 利用的 6.x 时代 CPU 入口区技巧在 3.10 上不存在，el7 会随机化直接映射基址，等等）。每篇 writeup 都记录了自己的解决方案。
该 bug 与触发：你不需要任何特权、用户命名空间或任何其他条件。任何本地用户均可。
每条武器化利用链都在其 writeup 中说明了自身的暂存阶段。el7 利用链从命名空间内 root 开始暂存（实际上：任意 RCE 进入特权容器——这是通过 MYSQL 实例的 UDF 插件路径验证的，这是非常典型的处境）。暂存后的内核侧工作仅使用：
/proc/self/pagemap（含真实 PFN，需命名空间内 CAP_SYS_ADMIN）/proc/kcore（el7 上需命名空间内 CAP_SYS_RAWIO）/proc/kallsyms（未掩码，kptr_restrict=0 或 CAP_SYSLOG）这些都不是漏洞本身，只是暂存便利手段，用来替代我尚未构建的信息泄露原语。
具体到 el7，完全无特权的利用链因结构性原因而受阻（3.10 的 BUG_ON、无 CEA、内核 .data 中无静态伪造锁对、pagemap PFN 门控）。
el7 的 writeup 包含完整分析和研究方向，主要是头部地址信息泄露原语。
panic_on_oops=1 的主机上，错误的遍历会导致 panic 并使机器宕机，因此在测试时请将其视为威胁模型的一部分。el7/
WRITEUP.md 针对 el7 利用链的完整技术 writeup
ghostlock_el7.c 针对两个已测试内核的单一文件 PoC
3bfdc63936dd（“rtmutex: Use waiter::task instead of current in
remove_waiter()”）；NPD 后续修复 40a25d59e85b