企业官网建设流程全解析

CyberMeowfia 是 NebuSec 开源的漏洞利用 PoC 仓库，而其中的核心武器 kernelsnitch 是一款基于futex 哈希冲突的 KASLR 泄漏模块——它不需要任何特权、不需要读 /proc/kallsyms，仅靠一个普通的 futex 系统调用和 CPU 计时，就能从内核地址随机化（KASLR）的保护中"撬"出mm_struct的内核地址，为后续提根铺平道路。本文带你从零看懂它的原理、API 与跨 CVE 的复用方式。⚠️ 仓库明确提示：这些 PoC 可能修改系统文件、导致崩溃或数据损坏，仅可在自有或获授权的设备上运行。

一、为什么内核利用离不开 KASLR 泄漏

KASLR（Kernel Address Space Layout Randomization）会随机化内核镜像在物理内存中的加载位置。对一个漏洞利用程序来说，拿到 UAF（use-after-free）原始原语后，还必须知道内核"slide"（偏移量），才能让伪造的函数指针（如commit_creds）指向正确位置。

传统方案（读/proc/kallsyms、/dev/kmem）都需要高权限。kernelsnitch 的思路则完全不同：把泄漏问题转化为一个纯用户态可观测的计时侧信道问题，核心只依赖两样东西：

• futex系统调用（任何普通进程都能调用）
• rdtsc/cntvct_el0等高精度计时指令

二、原理拆解：futex 哈希冲突如何变成"泄漏神谕"

2.1 内核侧的 futex 哈希表

内核为每个 futex 维护一张哈希表，key 由三部分构成（private futex 场景下）：

• mm：当前进程的struct mm_struct指针
• address：页对齐后的用户态地址
• offset：页内偏移

哈希函数采用 Jenkins 哈希jhash2，表大小为256 × 在线 CPU 数，可在 futex_hash.h 的futex_init()与futex_hash()中看到完整复刻。

关键点：同一个 key（mm + 地址）的 futex 操作会落在同一个哈希桶；桶里挂的等待者越多，futex 操作的耗时越长。

2.2 构造"堆积桶"并测量时间差

kernelsnitch_find_collisions()（见 kernelsnitch.h）分两步：

1. 堆积目标桶：先向某个固定桶（ID 128）挂入 256 个（APPENDED_FUTEXES）等待线程，让这个桶明显慢于其他空桶；
2. 扫描冲突地址：再对预留的 64 GiB 虚拟地址空间（FUTEX_SZ，L21）中的候选地址逐个执行FUTEX_WAKE并计时。__measure()（L160-L179）重复测量 16 次取前 4 快均值做信号处理，凡是耗时超过基线 10 倍（KERNELSNITCH_THRESHOLD_MULT）的地址，就是与目标桶发生哈希冲突的用户态地址。

这样，攻击者就收集到一组"哈希签名一致的已知用户态地址"。

2.3 暴力搜索：用冲突签名反推 mm_struct

既然futex_hash(addr, mm)对所有冲突地址都相等，那么mm_struct的真实地址就一定是让这组哈希同时相等的那个候选值。kernelsnitch_bruteforce()（L353-L374）将恒等映射区（x86_64 为0xffff888000000000起的 1TB 窗口，L30-L31）切分给多线程，按 slab 对齐、以sizeof(mm_struct)为步长逐一试算，命中即得泄漏的mm_struct地址（L195-L240）。

由于mm_struct位于恒等映射的 slab 中，泄漏它的地址本身就等价于解开了内核 slide——这就是"基于 futex 哈希冲突的 KASLR 泄漏"。ARM 开启了 MTE 时，还会对候选地址的 tag（高 4 位）做 0~15 穷举（L218-L233）。

计时后端按架构自适应：Intel 用rdtsc、AMD 用RDPRU、ARM 用cntvct_el0，见 timeutils.h。

三、快速上手：四步状态机 API

kernelsnitch 被设计成带状态机（enum kernelsnitch_state）的四阶段流程，所有状态放在MAP_SHARED匿名内存中，因此碰撞扫描可以在另一个子进程里执行，这是跨 CVE 复用的关键：

kernelsnitch_setup(mm_struct_sz, mm_slab_order, thread_cnt, collision_cnt, verbose, mte) → KERNELSNITCH_INIT kernelsnitch_find_collisions(ks) → KERNELSNITCH_COLLISIONS_FOUND / NOT_FOUND kernelsnitch_bruteforce(ks) → KERNELSNITCH_MM_FOUND / MM_NOT_FOUND kernelsnitch_cleanup(ks) // 返回泄漏的 mm_struct 地址或 -1

最简调用只有一个入口kernelsnitch(mm_struct_sz, mm_slab_order)（L446-L448），线程数默认取2 × CPU 数、冲突数取 16。

各目标平台的典型参数（MM_STRUCT_SZ必须与目标内核一致）：

四、跨 CVE 复用：一套武器，多线战场

kernelsnitch 在仓库中至少以 4 种形态出现，覆盖 Linux 桌面发行版与 Android 两条攻击线：

4.1 Linux 发行版 LPE 通用组件 🐧

CVE-2026-31678（Fedora 44）、CVE-2026-52912（Fedora 44）、CVE-2026-52923 / CVE-2026-52933（RHEL 10 / Fedora）等多个 LPE 目录都内嵌了同一套kernelsnitch/头文件组，例如 kernelsnitch 目录；Debian 13 的 CVE-2026-43042 则内联为单文件 kernelsnitch.h。

以 CVE-2026-31678 为例，它把 kernelsnitch 与"已知页锚定"结合（known_page.c）：

1. 子进程clone_leaker（L99-L115）在独立进程里做碰撞扫描，主进程同时用 UAF 原语"groom"mm 对象；
2. 泄漏出子进程mm_struct后，按 ±2GiB、±4GiB 调整 physmap 基址做多轮暴力搜索（L390-L407）；
3. 通过 socketpair + 分片sendmsg（reclaim_known_page）让 sk_buff 精确回收该页，把"泄漏"升级为"可控内核页"。

4.2 Android Pixel 根机链（GhostLock / Ndays）📱

• IonStack · CVE-2026-43499（GhostLock）：15 年来一直存在的栈 UAF，可根植 Android 17 的 Pixel。kernelsnitch 负责在 pipe.c 中定位泄漏页，再由 util.c 封装setup_kernelsnitch()/cleanup_kernelsnitch()，泄漏出的 mm 地址被& ~(ORDER3_SIZE-1)对齐成 kernel page 基址（exploit.c），供后续伪造fops/init_task使用（见 root.c 读取init_tasks.prev的经典套路）。targets/ 下按 Pixel 机型（blazer、caiman、tokay、comet、komodo、frankel、rango、mustang）维护各自的指纹与偏移。
• Nday · CVE-2026-43074（eventpoll RCU UAF）：Pixel 10 Pro 上 >80% 成功率的 LPE，见 README.MD 与 kernelsnitch 组件。
• Nday · CVE-2026-64560（CPU timer UAF）：单文件内联了 kernelsnitch 状态机（exploit.c），并在KASLR_SLIDE_MIN/END（L337-L339）窗口内校验泄漏出的 slide，成功即可关闭 SELinux 获得 root shell。

4.3 姊妹模块 leak_fast：slide 的交叉验证

部分 Linux PoC（如 leak_fast.c）还用prefetch计时在 1GB 窗口内搜索内核镜像/physmap 边界，与 kernelsnitch 互相校验——两条独立侧信道都指向同一 slide，才算可信。

五、编译与运行

所有目录都提供静态链接的 Makefile（musl-gcc，-static -O2，并带check目标验证无动态依赖与未解析符号），例如：

cd security-research/Linux-CVE-2026-31678-Fedora-6.19.10-300 make # 产出 exploit 静态二进制 make check # 验证 file / readelf 无 INTERP、无 UND 符号

对应 Makefile。Android 侧同样有 Makefile，产物需在对应指纹（target.h中的BUILD_FINGERPRINT）的 Pixel 设备上运行。

六、安全启示与防御建议 🛡️

1. 侧信道比想象中更深：kernelsnitch 证明，只要futex哈希表对私有 futex 暴露了 mm 指针参与的哈希，计时即可反推内核地址——防御上需要审视 futex 哈希的熵源与桶链表长度的可观测性；
2. 参数与内核版本强绑定：MM_STRUCT_SZ、MM_ORDER必须精确匹配目标内核，这也是该模块难以"盲打"的原因；
3. 对运维的建议：升级到包含 futex 相关修复的内核版本、对可疑静态无依赖二进制保持 EDR 告警，比依赖 KASLR 单独兜底更可靠。

七、资料速查 📚

• 模块主体：kernelsnitch.h（含 setup/collisions/bruteforce/cleanup 全链路）
• 哈希复刻：futex_hash.h · 计时：timeutils.h · 工具宏：utils.h
• 已知页锚定实战：known_page.c
• Android 目标适配：targets 目录 · oriole 专用 exploit
• 仓库全貌：README.MD