做内核堆利用题的朋友，应该没少被 CONFIG_SLAB_FREELIST_HARDENED 这个编译选项恶心过。以前打用户态堆题，改一下 freelist 的 next 指针就能拿到任意地址分配；到了内核里，这套老剧本直接失效——写入的 next 指针会被校验、会被异或混淆，随手一改就是内核 panic。我在 kernoob 靶场里把两种常见解法完整走了一遍之后，才真正理解这个防护到底在拦什么、哪些攻击面是它管不到的。这篇文章不聊理论空架子，直接把 SLUB 分配器的加固机制拆开，再结合 kernoob 里的实际场景讲两种绕过路线：一种是低字节部分覆盖，把 freelist 头引到隔壁对象；另一种是干脆不碰 freelist，直接走对象类型混淆。适合已经在玩内核堆利用、但对防护机制还停留在“知道有这个东西”层面的朋友参考。
1. 先搞清楚我们在对抗什么
1.1 SLUB 的 freelist 结构：一个由对象自己背着的链表
内核里默认的 SLUB 分配器维护空闲对象的方式，和用户态 glibc 的 bins 有点类似但更简单：每个 slab 页上有一批固定大小的对象，空闲对象之间通过一个单向链表串起来。关键点是，这个链表的 next 指针不保存在分配器的元数据区，而是直接写在空闲对象本身的开头。也就是说，一个对象被释放之后，它的第一个机器字就变成了指向下一个空闲对象的指针。
分配路径也很直白。每个 CPU 上有一个 freelist 头，指向当前 CPU 第一个可用的空闲对象；分配时直接取出这个头，然后从该对象开头读取下一个空闲对象的地址，更新 freelist 头，返回原头对象给调用者。因为对象数据本身就充当链表节点，这比维护独立链表结构省内存，但也埋下了隐患：如果攻击者能往空闲对象里写数据，就能改写这个 next 指针。在老的防护配置下，把 next 改成任意地址之后，下一次分配就能返回那个地址，经典的任意地址分配就这么来的。
1.2 HARDENED 做了什么：异或混淆加上双重释放检测
CONFIG_SLAB_FREELIST_HARDENED 这层防护，核心是两件事。第一件是把写入空闲对象的 next 指针做异或混淆：每个 slab cache 在创建时都会生成一个随机数当作密钥，存储 next 指针时用“真实地址 XOR 密钥”的结果写进对象；取出时再用同一个密钥 XOR 一次还原。这个密钥存放在 kmem_cache 结构体里，攻击者单纯堆溢出是拿不到的。第二件是加入了双重释放检测：释放对象进 freelist 时，如果发现当前 freelist 头正好就是待释放对象，说明这个对象已经在链表里了，属于 double-free，直接报错甚至 panic。
很多初学者会把 CONFIG_SLAB_FREELIST_HARDENED 和 CONFIG_SLAB_FREELIST_RANDOM 搞混。后者做的是 slab 页初始化时把空闲对象顺序打乱，让攻击者无法准确预判相邻对象在物理页里的排列，属于增大风水难度的防护；前者则是针对 freelist 指针本身的机密性和完整性做校验。两者经常同时开启，但思路完全不同。遇到这类题，第一步永远是用/proc/config.gz确认到底开了哪些选项，别凭感觉猜。
1.3 kernoob 靶场里这两种解法意味着什么
kernoob 是一套面向内核漏洞利用的练习环境，题目一般挂一个带漏洞的内核模块，漏洞类型通常是 UAF、double-free 或越界读写，目标是从普通用户态拿到 root 权限。靶场里的题普遍开启 KASLR、SMEP、SMAP、CONFIG_SLAB_FREELIST_RANDOM 和 CONFIG_SLAB_FREELIST_HARDENED，属于比较贴近真实难度的配置。
我在 kernoob 遇到的这类题目，正好是同一个漏洞点可以走两条完全不同的利用链。一是直接攻 freelist：虽然 next 被混淆了，但攻击者仍然具备对空闲对象的部分写能力，只要利用方式足够精细，就能绕过异或校验；二是放弃 freelist 攻击面，转而利用同 cache 的对象重叠，构造类型混淆，改函数指针完成劫持。两条路各有各的难点，也各有各的适用场景。下面的内容就把这两条路按实操顺序拆开讲。
2. 加固之后还剩哪些缝
2.1 低字节写是绕不开的突破口
CONFIG_SLAB_FREELIST_HARDENED 的混淆逻辑是整字异或，也就是说存储值的高位和低位都与真实地址的对应位做了 XOR。看起来无懈可击，但有一个关键弱点：如果攻击者不是覆盖整个 next 指针，而是只覆盖它的一个字节或者两个字节，那么异或密钥的高位部分依然参与运算，但攻击者可以通过控制被覆盖字节的内容，间接控制解码后该字节的取值。
在小端序的 x86_64 上，对象开头的第一个字是内存里低地址开始的 8 个字节，其中最低有效字节位于最低地址。如果漏洞是向低地址往高地址的越界写，或者 UAF 中我们能控制写入的长度，那么恰恰可以只修改 next 指针的低位字节而保留高位。解码之后，新指针的 high 部分不会变（因为存储值高位没变，密钥高位也没变），只有低字节变成我们指定的值。这意味着：我们能做的不是把 next 改成任意地址，而是把 next“拨动”到与原指针非常近的地址上去，比如同一 4KB slab 页内偏移差几个对象的位置。
这个攻击面在加固之后依然是有效的，因为校验机制没有对“next 必须指向本 slab 页内的合法对象”做强制约束。它只负责解码，不负责验证解码结果的合法性。内核真正可以容忍这种同页偏移吗？从攻击角度讲，只要目标地址上恰好在下一个分配请求中被当作对象返回，我们就可以通过后续写入完成劫持。所以，低字节覆盖不是强攻防线，而是顺着防线的逻辑找缝隙。
2.2 不碰 freelist 也能完成利用：类型混淆面
freelist 加固只会保护“空闲对象的 next 指针”，它不会保护“已分配对象内部的数据字段”。这是很多人忽略的一点。当一个漏洞允许我们往已分配对象里写数据时，我们可以直接修改对象内部某些字段，比如函数指针、ops 指针、长度字段，而根本不用管 freelist 是什么状态。
在内核堆利用里，这就是对象类型混淆的常见形式：漏洞对象和受害者对象落在同一个 kmem_cache 里，分配器返回给我们一个我们以为是 A 类型、实际内存里已经被 B 类型对象占用的地址。A 对象里的可控字段恰好覆盖了 B 对象中一个会在后续操作中被调用的函数指针。整个过程里我们没碰任何空闲链表，CONFIG_SLAB_FREELIST_HARDENED 再强也拦不到这一层。
这种思路在真实内核漏洞利用里很常见，也是为什么很多防护选项都开了的内核依然能被攻破。安全机制拦截的是具体某一种攻击模式，只要换成另一种模式，原先的防御就等于零。
2.3 两条路线怎么选
直接对比一下两种思路的适用场景：
| 维度 | 部分覆盖 freelist | 对象类型混淆 |
|---|---|---|
| 攻击目标 | freelist 头的 next 指针编码值 | 已分配对象内部字段 |
| 是否受 HARDENED 影响 | 直接受影响，但可利用低字节绕过 | 基本不受影响 |
| 关键前置条件 | 能部分写空闲对象；目标地址与原地址同页邻近 | 能找到同 cache 且含函数指针的对象 |
| 对堆风水要求 | 极高，需要精确控制分配释放顺序 | 中高，需要让两类对象重叠 |
| 难度上限 | 偏重技巧和偏移计算 | 偏重利用链设计和提权方式 |
我的经验是，如果题目明确给了部分写能力且对象尺寸很小（比如 0x20、0x40），走部分覆盖最直接；如果题目给的是较大的越界写或者 UAF 写，对象类型混淆的容错更高，后期调试也更省心。kernoob 相关题目之所以常出现“两种解法”，正是因为题目代码留了足够的灵活性，两种方式都能打通。
3. 解法一：保留校验位，只改低字节——把 freelist 头引到隔壁对象
3.1 核心原理：异或运算的“局部可控”特性
设某个 slab cache 的混淆密钥为 K，对象原始存储的 next 编码值为 S = next_addr ^ K。当我们只修改 S 的最低一个字节时，S 的低字节变成 S'，而高 7 个字节不变。解码得到的新地址就是：
next_addr' = (S & ~0xFF) | S'_low ^ (K & 0xFF)
由于 S 的高位没变，解码结果的高位部分与 next_addr 完全相同，只有低字节变化。这意味着我们能得到的 next_addr' 必定落在原 next_addr 所在的 256 字节范围内。如果原 next 指针指向的地址在某个 slab 页的中间，那么目标地址也在这个 256 字节范围内，通常覆盖同一页里的几个相邻对象。
这也是为什么该方法需要堆风水配合的原因。直接随机修改低字节，很可能把 next 指向一个不可控或已分配出去的地址，导致分配器返回异常对象。要让攻击可控，就必须让“原 next 地址”和“目标对象地址”在同一个 256 字节窗口内，并且清楚知道目标对象与当前 freelist 头之间的偏移。
3.2 堆风水：让目标对象待在偏移 0x100 内
我在复盘时设计过一个最简单的布局。假设漏洞对象是一个 0x40 大小的堆块，漏洞点是 UAF 写。我先把 victim 对象和漏洞对象都申请出来，让它们在同一个 slab 页里相邻排列。由于 CONFIG_SLAB_FREELIST_RANDOM 会打乱空闲顺序，直接连续分配不一定相邻，所以需要多喷几次，通过观察实际地址来调整。
具体顺序大致是：
- 连续申请一批 0x40 的对象，填充一整页 slab。
- 释放其中一个漏洞对象，让它成为 freelist 头。
- 再申请两个对象，让 freelist 头位置的 next 指向我们预先释放的目标 victim（这个目标在释放顺序上要排在漏洞对象之后，且与原 freelist 头在同一页）。
- 利用 UAF 对漏洞对象写入，只修改其 next 指针的低字节，使其指向相邻的 victim 对象。
这里的关键点在于弄清楚目标 victim 与 next 原地址的差值。如果差值小于 0x100，一次释放/分配操作中修改低字节就够了。我在实际调试中更喜欢先故意泄漏一次原始的 next 编码值，再通过让分配器多返回一次对象来观察真实分配顺序，从而反推目标对象的偏移。纯猜低字节的话成功率只有 1/256，虽然 CTF 里重启爆破可行，但效率太低，不推荐。
3.3 一次典型操作的伪代码思路
下面这个片段不是可以照抄的最终 exploit，而是演示部分覆盖这一步的核心操作。重点是理解写入长度和写入内容之间的关系。
// 假设 vuln_ptr 指向已释放的漏洞对象 // 目标是修改该对象开头的 next 指针的低字节 uint64_t encoded_next = *(uint64_t *)vuln_ptr; // 读出编码后的 next uint64_t fake_low = target_offset_low; // 目标低字节 // 只回写低字节，保留高 7 字节 uint64_t new_encoded = (encoded_next & ~0xFFull) | fake_low; write_u64(vuln_ptr, new_encoded); // UAF 写如果只能写一个字节，更简单：
write_u8(vuln_ptr + 0, fake_low);写完后再分配两次，第一次分配会返回原 freelist 头，第二次分配就可能拿到被篡改后的假 next。拿到这个假对象后，后续要做的是在这个假对象上伪造数据，或者直接把它当成受害者对象的替身进行类型混淆操作。
3.4 成功与失败的分界线
这个方法最容易翻车的地方有三个。第一，修改的低字节必须保证解码后的地址落在合法对象起始位置，否则分配器可能直接因为对象内容异常而在后续释放时触发校验崩溃。第二，目标对象必须处于空闲状态，也就是它得在 freelist 里。如果目标对象已经被分配出去，那么你引过去的 next 指向一个已占用对象，后续分配会返回一个“假空闲对象”，读写时容易踩到正在使用中的数据。第三，SLUB 有 per-CPU partial 和 CPU partial 的逻辑，freelist 头不一定就是全局链表里你释放的那个局部头。释放后如果有其他 CPU 的分配请求介入，freelist 可能被换到另一个 CPU 上，导致你的部分覆盖根本不在当前活跃 freelist 上。
所以我在操作时养成了一个习惯：在断点调试阶段，先看一下当前 CPU 的 freelist 头地址，确认它就是我们 UAF 的对象。内核里这个值存在每个 CPU 的 kmem_cache_cpu 结构体里，用 gdb 直接查看即可，比瞎猜稳得多。
4. 解法二：不碰 freelist 头，让受害者对象替我们执行
4.1 从“改指针”到“改字段”的思路转换
第二种解法更直接：既然改 freelist 指针会被混淆、会被校验，那我就不去改它，转而去改一个已分配对象内部的可执行字段。内核里很多对象都带有函数指针，最常见的是各种 ops 结构体、timer_list 的回调、seq_operations 里的 show 指针。只要我们能对一个受害者对象写入可控数据，这些字段全都能变成我们的跳板。
这个思路的好处是，它完全绕开 CONFIG_SLAB_FREELIST_HARDENED 的管辖范围。防护机制只负责空闲链表完整性，不负责已分配对象内部的语义。因此只要漏洞点允许“写已分配对象”，加固选项就形同虚设。内核开发者显然也知道这点，所以后续又加了 struct 随机化、控制流完整性之类的防护，但在老内核版本里，类型混淆仍然是最稳的路径。
4.2 在同 cache 里找函数指针对象
要在同 cache 里找到带函数指针的对象，先要看目标 cache 的尺寸。比如一个 0x40 的 cache，很多常见内核对象都能落进去，但并不是每个对象都适合当受害者。我的选择标准有三个：一是对象开头或者偏移处存在一个会在特定触发路径中被调用的函数指针；二是对象大小和漏洞对象一致，能通过堆风水让两者重合；三是触发调用所需的操作足够简单，比如打开一个文件、读一个 proc 接口，而不需要复杂的内核条件。
以 seq_operations 为例，它大小很小，里面存了一组函数指针，打开对应的 proc 文件时内核会填充它，调用 read 时就会跳到里面的 show 指针。如果能让漏洞对象和它重叠，我们只需要在重叠对象上把 show 字段改成目标地址，然后 read 一次，控制流就过去了。这个模式在内核 CTF 里快被用烂了，但正因为触发条件简单，它的稳定性非常好。
4.3 完整利用链顺序
完整走一遍类型混淆利用链，大致分四步：
- 泄漏：先通过漏洞读出 victim 对象里的内核地址，用来绕过 KASLR。如果漏洞点支持任意读，这一步最方便；如果不支持，需要借助其他信息泄漏接口。
- 布局：喷射大量 victim 对象，让其中一个与漏洞对象落在同一 cache。这里可以直接看 /proc/slabinfo 确认 cache 名称和数量，再用分配的先后顺序做粗略控制。
- 覆盖：通过 UAF 或越界写，把 victim 对象内的函数指针字段改成我们想要的目标地址。这个目标地址可以是 ROP gadgets 地址，也可以是某个函数地址。
- 触发：调用对应的操作（read、write、ioctl 等），让内核跳转到被篡改的函数指针。
提权环节一般有两种选择：一种是通过 ROP 链关闭 SMEP/SMAP 后执行用户态代码，另一种是直接改写 modprobe_path 指向我们准备好的脚本，然后触发内核执行。后面这种方式需要一次任意写原语，更依赖漏洞能力。
4.4 两种解法的能力对比和选择建议
在 kernoob 相关题里我两种都试过。整体感觉是：解法一更适合“小尺寸对象 + 精细部分写”的场景，它最终的利用原语非常强——能把分配器引到任意附近对象，等于给了任意地址分配；但调试成本高，偏移算错一个字节就 panic。解法二更依赖漏洞能写多少字节，通常需要至少 8 字节的连续写，但它生成的利用链更直观，每一步都可以单独验证，前后端解耦，排查起来舒服很多。
另外要提醒一句：解法二并不是完全不受 SMEP/SMAP 影响。如果内核命令行了 SMEP 和 SMAP，直接跳用户态代码是行不通的，需要搭配内核 ROP 链，或者选择修改 modprobe_path 这种不需要执行用户态代码的提权路径。这也是为什么很多解法二最终都落在改名脚本上，而不是去弹 root shell 后再执行命令。
5. 实操环境与步骤复盘
5.1 最小复现环境怎么搭
本地复现这类题目，最省事的方式是用一个自定义内核加一个最小根文件系统，跑在 QEMU 里。我在练习时用的是某个较新的 5.x 内核源码，在 defconfig 基础上打开下面几项：
CONFIG_SLAB_FREELIST_HARDENED=y CONFIG_SLAB_FREELIST_RANDOM=y CONFIG_KASAN=n CONFIG_PAGE_TABLE_ISOLATION=n调试阶段建议临时关掉随机化和 KASLR，等思路跑通再全开验证。KASAN 必须关，否则漏洞触发点很容易被 KASAN 先拦下来，干扰对分配器行为的观察。编译完成后用 busybox 做根文件系统，通过 initramfs 直接启动，省去磁盘镜像的麻烦。
QEMU 启动参数里建议加上-s -S用于 gdb 远程调试，同时加nokaslr来固定内核布局，方便在调试阶段直接使用符号地址。真正验证阶段再切回默认参数，确保利用方式不依赖关闭 KASLR。
5.2 验证防护开启的关键命令
进入系统后第一件事就是确认防护状态：
zcat /proc/config.gz | grep SLAB_FREELIST cat /proc/slabinfo | head cat /sys/kernel/slab/kmalloc-64/aliases如果内核没开 proc config，可以直接在内核源码目录里查.config文件。刚开始玩的时候我犯过一个低级错误：以为自己开了 HARDENED，结果编译时被覆盖成默认关闭，导致前面调试的所有结论在正式环境里完全对不上。所以无论多着急，只要换内核配置，就必须重新确认一次。
5.3 调试手段：gdb 符号、断点位置、ftrace
调试内核堆利用，我最常用的还是 gdb 配合 vmlinux 符号。set_freepointer 和 get_freepointer 这两个函数是绕不开的断点位置。在 gdb 里分别下断：
break set_freepointer break get_freepointer分配对象时观察 get_freepointer 的参数和返回值，就能直接看到解码前后的地址。如果伪造的 next 被解码成了奇怪的值，这一个断点立刻暴露问题。释放对象时观察 set_freepointer 写入的编码值，能确认我们 UAF 写的是不是恰好覆盖了这个区域。
ftrace 也可以用来跟踪分配路径，但我觉得在 CTF 级别题目里没必要，gdb 单步观察就足够清晰了。唯一的坑是内核开了太多优化后，set_freepointer 会被内联进 do_slab_free，断点可能打不进去。解决办法是直接对__slab_free下断点，再通过 disassemble 找到内联后的校验逻辑。
5.4 复盘时踩过的三个坑
第一个坑是 per-CPU partial 的干扰。SLUB 在每 CPU 上有一个 partial 链表，对象释放后先进入 freelist，freelist 过长时才会批量移入 partial。如果我释放后立刻分配，逻辑简单；但如果中间插入其他分配操作，freelist 头可能变成另外的对象，部分覆盖就打偏了。解法是在漏洞触发前后尽量减少其他分配噪声，必要时用同一个 CPU 执行整个序列。
第二个坑是 kmalloc 的 cgroup 版本。开启了 CONFIG_MEMCG_KMEM 的内核里，带 __GFP_ACCOUNT 标志的分配会走 kmalloc-cg 系列 cache，和你以为的 kmalloc-64 并不在同一个 cache。如果漏洞对象用普通 GFP_KERNEL 分配，受害者对象却用带 ACCOUNT 标志的分配方式，两者永远不会重叠。这个问题在调试类型混淆时非常隐蔽，我花了一整个晚上才定位到。
第三个坑是翻译偏移时的字节序错误。x86_64 是小端，我一度在计算低字节偏移时把地址高低位写反，结果改了高字节而不是低字节，整个 next 指针直接变成野指针，内核立刻 panic。后来我把地址打印出来逐字节对了一遍，才意识到是这个问题。遇到这种奇怪偏移，先停下看内存里的原始字节，不要靠手算。
6. 常见问题快速排查表
以下是我在实操中遇到过的典型问题，整理成速查表，遇到类似现象可以直接对号入座。
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 分配时直接 panic，报 invalid freelist pointer | 解码后的 next 不在合法页范围内，或地址未对齐 | 检查低字节计算是否覆盖了不该改的位；确认目标对象是否在同一页 |
| UAF 读出的 next 值是乱码 | 这是正常现象，读出的是编码后结果 | 不要直接把它当真实地址，结合分配行为反推偏移 |
| 部分覆盖后分配返回的对象不是想要的 | 原 next 地址与目标对象偏移超过 0x100 | 重新设计分配顺序，缩小偏移窗口 |
| double-free 检测触发，内核直接报错 | 释放对象时发现当前 freelist 头就是该对象 | 检查释放流程中是否重复释放了同一个对象，避免让同一个对象连续进入 freelist |
| 受害者对象永远不重叠 | 可能走了不同 cache，如 kmalloc-cg | 检查分配标志里的 __GFP_ACCOUNT，确保两者在同一 kmem_cache |
| 类型混淆后触发调用 panic | 函数指针被改成非法地址，或 SMEP/SMAP 拦截 | 确认目标地址是否属于内核态可执行区，必要时换 ROP 或 modprobe_path 方案 |
| 调试断点打不进去 | 函数被内联 | 对内联后的外层函数下断点，或编译时关掉部分内联优化 |
| 在 QEMU 里跑不通但本机可以 | 内核配置不一致 | 重新 diff 两份 .config，重点看 SLAB、KASLR、SMEP/SMAP 等选项 |
排查问题的时候有一条主线：先确认漏洞点是否真的写到了目标内存，再确认分配器状态是否如你所料。很多人卡住是因为漏洞点根本没命中，后续全是在分析错误的地址。用 gdb 在写入位置打断点，直接看内存布局，可以省下大量时间。
7. 一些关于学习顺序的心里话
接到这类题目，我最深的体会是：不要一开始就背解法，先把内核源码里对应分配器的那几段代码读明白。CONFIG_SLAB_FREELIST_HARDENED 的完整实现只有几十行，set_freepointer、get_freepointer、freelist_ptr_encode、freelist_ptr_decode，花半天读清楚，比盲目调一星期 bug 都值。你只有知道校验发生在哪一步、校验的是哪个值，才会明白为什么低字节覆盖能绕过，为什么类型混淆能完全无视它。
第二个经验是，内核堆利用的调试效率往往取决于你对内存布局的“可视化程度”。我建议在本地环境里把打印内核指针的辅助函数写好，每个关键步骤都输出地址、偏移和 cache 信息。等题目做多了，你会有一种直觉：看到一个偏移，就能大致判断出这个对象在 slab 页里的位置，面对 HARDENED 这种防护时下手会稳很多。
如果你现在正卡在某道 kernoob 题上，不妨先把工具链准备好，再回到源头把 SLUB 的分配、释放、freeze 和 unfreeze 流程过一遍。题目本身是固定的，但思路是可以复用的——下次再遇到开启 CONFIG_SLAB_FREELIST_HARDENED 的题目，你就知道该从哪里切开防线了。
