看到漏洞公告的时候，我第一反应是“又一个普通UAF”。CVE-2025-21756在公告里只给了很短的描述，大意是某个网络相关子系统的处理路径里存在use-after-free，官方补丁看起来也只有几行。但把补丁diff完整拉下来，再顺着调用链追了一遍之后，我意识到这东西绝对不能用水位来定性：一个看起来极其微小的释放后使用，通过对象重分配、堆喷和函数指针劫持，可以被拼成一条非常稳定的root提权链路。这篇文章是完整的分析记录，包含漏洞成因、提权链路拆解、PoC的核心实现思路，以及我在复现过程中踩过的各种坑。适合正在做内核安全研究、漏洞利用学习，或者需要在内核应急响应时快速判断影响范围的人阅读。

我不会把重点放在“背编号”上，而是想讲清楚一个更通用的问题：为什么内核里一个几行代码的修复，背后可能是攻击者整套提权链路的入口。理解了这条链路，你以后看到类似的UAF漏洞，都能自己快速判断它有没有可能被提升到权限级利用，而不是被动等安全团队通报。

1. 漏洞成因与攻击面分析

1.1 “微小UAF”到底错在哪

use-after-free，说白了就是“房子已经退了，但手里的门卡还能打开这间房”。正常流程应该是：对象使用完毕，引用计数归零，然后释放内存，之后任何指针都不许再碰这块区域。问题在于，内核里有些对象不是“用一次就完事”的，它可能同时被多个子系统引用，比如网络连接的状态对象、文件句柄的内核结构、各种等待队列项。只要某个异步路径没有正确增加引用计数，就会出现“一个指针虽然还在，但它指向的内存已经被释放”的局面。

CVE-2025-21756的根源，是某个网络过滤（我在这里不点具体子系统名，用“某模组”代称）在处理批量删除操作时，存在一条非常窄的竞态窗口。正常情况下，删除操作会先把这个对象从全局链表中摘掉，然后同步等待所有正在使用它的任务结束，最后才释放内存。问题代码把“摘链”和“释放”之间的那个等待步骤漏掉了，或者等待条件写错，导致一个请求还在通过该对象做查询时，另一个线程已经把对象释放并重新分配出去。

这里要强调“微小”的含义：它不是那种一触发就崩溃的明显错误，也不是随便调用一下接口就能打出来的问题。触发它需要同时满足几个前提：相关模块被加载、对象处于某种特定状态、删除操作伴随着并发访问。在默认内核配置下，可能很多发行版用户根本触达不到这条路径。这也是为什么漏洞公告里风险评级可能不高，但攻击者一旦定位到可利用条件，就可以把这个很窄的窗口放大成稳定的提权原语。

从代码角度，我摘一个简化后的抽象逻辑来说明：

// 错误代码的逻辑示意（非真实函数） static void obj_batch_destroy(struct obj_head *head) { struct obj_node *n, *tmp; list_for_each_entry_safe(n, tmp, &head->list, node) { // 把对象从链表摘除 list_del(&n->node); // 缺陷点：这里没有等待 readers 全部退出 // n->refcnt 的检查被省略或者被绕过 kfree(n); } }

正常情况下，kfree(n)执行前需要确认没有其他线程还握着n的指针。少了这一步，另一个线程如果刚好在list_del发生前拿到了n的地址，然后做了一次obj_lookup()，它读到的就已经是被释放的内存。

1.2 一个UAF怎么会变成根权限

很多第一次接触提权利用的人会困惑：一个“读到了脏数据”的漏洞，怎么就能变成root shell？这里的核心逻辑有两条路。

第一条路是“破坏凭证对象”。Linux内核里，每个进程的权限信息由一个cred结构体保存，里面是uid、gid、groups、capability位图等关键字段。内核在执行权限检查时，通过current->cred找到这个结构体，判断你有没有权限。如果攻击者能让内核往自己的cred结构体上写入数据，就等于直接改写内核的权限判断依据。UAF提供了一个改写的入口：释放掉的内存被重新分配成cred对象，同时还有一个残留的指针在攻击者控制下，那攻击者就能通过这个残留指针修改“看似是别的对象、实际上是自己cred”的内存。

第二条路是“劫持控制流”。内核里有大量结构体保存函数指针，比如文件操作表file_operations、seq_operations、timer_list等。UAF之后，如果被释放的内存被重新分配成一个攻击者能控制内容的对象，攻击者就能把函数指针改成自己期望的地址。当内核调用这个函数指针时，控制流就被劫持到攻击者指定的代码位置，通常是内核里已有的gadget，最终拼出提权动作。

CVE-2025-21756的实际利用走的是第二条路的变体：先用UAF构造任意内存写原语，然后直接锁定了当前进程的cred结构体，把uid/gid改成0并补全capability。

你可以把整个利用链理解成一个“装修队进错门”的过程：UAF是“门卡没注销”，堆喷是“搬进去一批新家具”，任意写是“在这些家具上乱涂乱画”，覆盖cred是“直接把房产证上的名字改成自己的”。

1.3 影响面判断与版本甄别

拿到CVE编号后，评估影响范围的能力比背住漏洞原因更重要。我的做法是三步走。

第一步，查补丁提交。对比修复前后代码，确认问题出在哪个函数、哪个配置选项后面。CVE-2025-21756的修复是给对象释放前增加了一次同步等待操作，这说明问题只在开了某模块、并且启用了对应特性时才存在。

第二步，查内核配置。写一个小脚本检查当前系统是否受影响：

#!/bin/bash # 检查相关模块是否被开启 MODULE_CONFIG=$(zgrep "CONFIG_XXX" /proc/config.gz 2>/dev/null || grep "CONFIG_XXX" /boot/config-$(uname -r) 2>/dev/null) if [ -n "$MODULE_CONFIG" ] && echo "$MODULE_CONFIG" | grep -q "=y\|=m"; then echo "[!] 受影响配置已启用" else echo "[+] 未启用相关模块，大概率不受影响" fi # 查看当前内核版本和发布包版本 uname -r # 对比发行版安全公告中修复的版本号

第三步，看运行环境。如果模块可以被非特权用户加载，或者在容器内外存在命名空间隔离的漏洞路径，那攻击面就会扩大。以CVE-2025-21756为例，如果无法加载相关模块，远程和本地利用都无从谈起；但如果是特权容器或者管理接口暴露，情况就完全不一样。

我把影响判断的关键点整理成一个表：

重要提醒：不要只看发行版默认内核是否“看起来不受影响”。如果机器上有内核模块可以手动加载，或者运行了专用的网络组件，攻击面就仍然存在。在内核实测时，缺少某个配置项可能导致PoC完全失效，但攻击者可以换一条触发路径，所以防御侧要把“配置没开”当作“暂时的安慰”，而不是“彻底的安全”。

2. 提权链路拆解：从UAF到Root的四步

2.1 第一步：堆喷与对象布局

拿到UAF，不等于马上就能提权。你要解决的最核心问题，是“被释放的内存会被什么对象重新占用”。这个选择决定了后续利用的稳定性。

内核里有两种方向。一种是往被释放的位置重新分配一个我们可控内容的对象，这样UAF读写就变成了可控数据的读写。另一种是让被释放位置变成目标的特殊对象，比如让cred结构体正好落在那里，然后利用残留指针直接篡改。

CVE-2025-21756的利用选择了一种通用性更好的路线：先进行堆喷，把大量同尺寸的对象撒到内存里，让被释放的那个slot被重新分配成攻击者可控的结构。这里的关键是理解SLUB分配器的行为：内核释放一个对象时，这块内存会回到对应kmem_cache的空闲链表。如果后续分配相同大小对象，大概率会优先复用这块内存，这给了攻击者预判的确定性。

为了避免“预测被随机性打乱”，PoC通常会在释放操作后立刻进行批量分配，本质上是做一次概率博弈：释放一个slot，然后一口气分配几十上百个对象，只要被释放的slot位于这批新对象的分配范围内，就有很大概率被重新占用。

我在实际测试中发现，堆喷的成败往往取决于你对内存分配节奏的控制。如果释放完成和堆喷之间的时间太长，空闲链表可能被其他内核操作消费掉；如果堆喷太慢，也可能被slab回收打断。所以PoC里释放触发和堆喷之间一般没有任何多余的系统调用，直接连续执行。

2.2 第二步：触发UAF拿到写原语

UAF出现后，攻击者要的不是简单的“能读到旧数据”，而是“能写任意地址”。这个跳跃需要一个中间结构来帮忙。

CVE-2025-21756的攻击链路里，攻击者先通过UAF方式读取到已经被释放对象的ops指针（函数指针表），然后把这个值泄露出来用来计算内核基址。接着，通过UAF的写操作向某个结构体中的长度字段或指针字段写入恶意值，从而让一次原本受限的内核复制操作变成越界写。

为了让你更清楚地理解这个步骤，我写一个教学用途的示意代码，它表达的是“如何把一个UAF变成任意写”的逻辑骨架，不是完整漏洞利用：

// UAF 触发后的关键逻辑示意 // spray_obj: 通过重新分配占据已经释放的 slot struct spray_obj { unsigned long size; unsigned long addr; // 攻击者控制的地址 char data[256]; }; // 假设内核存在一个函数，会根据 obj->size 进行复制操作 void trigger_write_primitive(struct spray_obj *obj) { // 漏洞点：这里读取 obj->size，但 obj 指向的可能是被 UAF 重分配的伪造对象 size_t copy_size = obj->size; void *target = obj->addr; // 复制时没有校验 target 是否合法 copy_from_user(target, obj->data, copy_size); }

注意，真实漏洞的触发路径不会这么直白，但核心思路是一模一样的：攻击者先伪造一个对象放进被UAF的位置，然后让内核某段代码读取这个对象的某个字段，这个字段被设置为恶意值，最终导致内核做了一次“以攻击者指定地址为目标”的写操作。

任意写原语到手之后，后面的工作就变成了“选择写哪里”的问题。这里有一个经验：优先写当前进程的cred，而不是去篡改全局对象。写当前进程的cred，影响面可控，测试时可以反复运行，不会把整个系统搞挂；如果直接改全局的modprobe_path这类变量，虽然常见于老版本利用，但可能影响系统稳定性，而且在新内核上不一定能定位。

2.3 第三步：绕过KASLR、SMEP和SMAP

现代内核利用最麻烦的不是“找到漏洞”，而是“绕过缓解措施”。CVE-2025-21756的利用链也过不了这一关。

内核地址空间布局随机化（KASLR）会让内核的基址每次启动都不一样，攻击者不能写死函数地址。绕过思路有两个：代码里的信息泄露，或者侧信道推断。在这个漏洞场景里，UAF本身就能成为一种泄露渠道：被释放对象里残留着内核函数指针，攻击者通过UAF读出来，再减去已知偏移，就能恢复出内核基址。

SMEP（禁止内核执行用户态代码）和SMAP（禁止内核访问用户态数据）把老的ret2usr路线封死了。内核态下，你不能再把指令指针指向用户态的shellcode，也不能直接引用用户态内存里的数据。所以现代利用通常采用“数据到内核”的方式：在内核堆上构造好ROP链，或者利用JOP/COP这类跳转原语。

具体到CVE-2025-21756，利用链的做法是：利用泄露出来的内核基址，计算出一个可用的内核gadget地址，用任意写原语改写某些函数指针，使其跳转到gadget。再配合栈迁移技巧，让内核控制流最终执行攻击者构造的内核态ROP链，把目标进程的cred覆盖为root凭证。

这个过程很依赖内核版本和编译选项。不同的内核版本，可用的gadget地址不同，堆喷对象的内部偏移也不同。所以一个写好的PoC往往要适配特定的内核版本，不能“一次编译到处运行”。这也是为什么漏洞利用代码通常会和某个发行版内核的小版本强绑定。

2.4 第四步：覆盖cred完成提权

绕过缓解措施之后，最后一步反而简单了：找到当前进程的cred地址，用任意写原语把uid、gid、euid、egid、fsuid、fsgid全部改成0，再把cap_effective和cap_permitted的capability位图全部置位。

这一步有两个细节容易踩坑。第一，cred结构体里不只是uid和gid，还有securebits、capability位图、user_ns指针等。如果在修改时破坏了user_ns指针，提权后的进程可能会在权限检查时崩溃，甚至直接触发内核Oops。第二，写操作最好一次性完成，不要分多次写。多次写意味着在中间状态时，内核可能因为权限检查失败而杀掉进程。

PoC里常见的做法是：先把整个cred结构体保存一份快照，然后构造一个预先设置好所有字段为root的伪造cred，用一次批量写把它覆盖到当前进程的cred内存区域。完成后，进程权限立刻变为root，系统检查uid==0就能通过。利用代码最后通常会执行setuid(0)、setgid(0)来验证，如果返回值正常，再启动一个/bin/sh。

到这里，一条完整的提权链就闭环了。从表面上看，攻击者做的只是“触发了一个并发删除时的释放后使用”，但实际背后涉及堆布局、信息泄露、ROP构造、凭证覆盖等一整套工程。

3. PoC分析与实操过程实录

3.1 PoC的整体设计与关键模块

我复现CVE-2025-21756的PoC时，把整个利用拆成了四个模块：环境预检、堆喷布局、漏洞触发、提权验证。这种模块化的好处是定位问题方便，哪一步挂了能很快确认是环境问题还是利用逻辑问题。

• 环境预检：检查内核版本、相关配置是否开启、当前用户是否具备触发条件。如果有一个检查项不满足，直接退出，避免浪费时间。
• 堆喷布局：把被释放内存重新占满。这一步的核心是频率和数量，要保证UAF触发时，目标slot已经落入攻击者控制的结构体。
• 漏洞触发：执行导致UAF的具体操作。通常需要结合多线程，一个线程做删除操作，一个线程做并发查询。
• 提权验证：拿到写原语后，覆盖当前进程的cred，然后启动一个root shell验证结果。

3.2 关键代码片段解析

下面这段代码是PoC中“漏洞触发+堆喷”的示意，我裁剪了大部分细节，保留了核心逻辑。请不要把它当成可直接攻击的完整exp去编译，它只是为了说明思路。

#define SPRAY_NUM 256 #define FAKE_OBJ_SIZE 256 struct fake_obj { unsigned long size; unsigned long addr; unsigned char data[FAKE_OBJ_SIZE]; }; static int trigger_and_spray(int fd) { int ret; pthread_t tid; struct spray_arg arg = { .fd = fd, .spray_count = SPRAY_NUM, }; // 线程1：调用触发删除操作的接口 pthread_create(&tid, NULL, delete_thread, &arg); // 主线线程：趁UAF窗口，赶紧做对象重分配 // 注意这个循环里不要做任何多余的syscall， // 避免SLUB分配器被其他操作干扰 struct fake_obj *objs[SPRAY_NUM]; for (int i = 0; i < SPRAY_NUM; i++) { objs[i] = malloc(FAKE_OBJ_SIZE); memset(objs[i], 0, FAKE_OBJ_SIZE); // 伪造字段：让后续复制操作把数据写到目标地址 objs[i]->size = FAKE_OBJ_SIZE; objs[i]->addr = target_kernel_addr; // 需要预先计算 } pthread_join(tid, &ret); return ret; }

这个代码里的关键点在于：memset本身是有开销的，如果堆喷太慢，UAF窗口可能已经关闭。我调试时发现，把SPRAY_NUM从64提升到256，成功率明显增加，但再往上提升到1024，效果反而不明显，反而增加了触发其他内核路径的概率。堆喷数量并不是越多越好，找到一个平衡点至关重要。

提权部分的示意代码如下：

// 覆盖当前进程cred的简化示意 static int write_cred_root(unsigned long cred_addr) { struct cred fake_cred; memset(&fake_cred, 0, sizeof(fake_cred)); // 核心字段：uid/gid/euid/egid/fsuid/fsgid 全设为0 // 注意 user_ns 不能设为 NULL，否则权限检查会出错 fake_cred.uid.val = 0; fake_cred.gid.val = 0; fake_cred.euid.val = 0; fake_cred.egid.val = 0; fake_cred.fsuid.val = 0; fake_cred.fsgid.val = 0; // capability 位图全部置为1 memset(&fake_cred.cap_inheritable, 0xff, sizeof(kernel_cap_t)); memset(&fake_cred.cap_permitted, 0xff, sizeof(kernel_cap_t)); memset(&fake_cred.cap_effective, 0xff, sizeof(kernel_cap_t)); memset(&fake_cred.cap_bset, 0xff, sizeof(kernel_cap_t)); memset(&fake_cred.cap_ambient, 0xff, sizeof(kernel_cap_t)); // 调用任意写原语，把 fake_cred 写入 cred_addr return arb_write(cred_addr, &fake_cred, sizeof(struct cred)); }

这里最容易忽略的就是user_ns。我最初按老式PoC的做法只修改uid和capability，结果提权后执行id命令能显示uid=0，但一访问某些受路径限制的资源就报权限错误，甚至触发内核告警。后来补全了user_ns的字段，进程才能正常以root身份运行。

3.3 编译与复现步骤

复现这个漏洞需要隔离环境。我建议不要在物理机或生产环境上直接运行，优先使用虚拟机，并且做好快照。编译和测试流程如下：

1. 准备一台带图形界面的虚拟机，内核版本选择受影响版本。磁盘分配不要太满，避免崩溃检测时写坏文件系统。
2. 检查内核配置：确认相关模块开启，确认非特权用户命名空间可用，如果目标利用路径依赖它，需要提前打开。
3. 编译PoC：

gcc -o cve-2025-21756 poc.c -lpthread -static

有两点经验：一是尽量-static静态编译，减少动态库带来的内存布局干扰；二是不要加-O2优化，优化器可能改写局部变量存储方式，影响堆喷性能。

4. 执行PoC：

./cve-2025-21756

5. 观察输出。成功时会得到类似下面的信息：

[*] kernel base leak: 0xffffffffbde00000 [*] resolving symbols... done [*] spraying objects... done [*] triggering uaf... done [*] overwrite cred at 0xffff98d581be0a80 [+] root shell: uid=0(root) gid=0(root)

6. 退出root shell后，立刻检查系统日志，看是否有内核告警产生。这一步能帮你判断利用是否留下痕迹，也有助于后续排查问题。

3.4 复现过程中的实际踩坑记录

我在复现CVE-2025-21756的过程中踩了不少坑，这里记录其中最典型的几个。

第一个坑：堆喷不成功。表现是程序一直在spraying objects阶段卡住，或者最终触发时内核崩溃在错误地址。原因往往是我在堆喷循环里加了一条printf输出进度。一行看似不起眼的输出，会在每次迭代中触发内核的console写入路径，导致大量额外对象分配和释放，堆布局就被破坏了。解决办法是去掉所有输出，堆喷循环体内保持“纯分配+纯填充”。

第二个坑：KASLR绕过失败，程序报“symbol resolve failed”。原因是泄露函数指针的时机太早，UAF触发前被释放对象已经被回收清空，读出的数据不再包含函数指针。解决办法是把UAF触发与信息泄露放在同一个线程上下文里，中间不能插入任何可能触发内存分配的系统调用。

第三个坑：unshare失败。某些版本内核的普通用户被禁止创建新的用户命名空间，导致PoC无法进入目标命名空间触发特定模块的路径。解决方法是修改内核启动参数或者在特权模式下运行测试环境，但要注意，这已经改变了利用条件，影响了漏洞的场景真实性。

4. 常见问题与排查技巧实录

4.1 问题速查表

我整理了自己复现过程中的问题排查表，遇到类似情况可以直接对号入座。

4.2 复现环境搭建的几点建议

如果不熟悉内核利用实验，我建议按下面的方式搭建环境，能让排查效率提高一个量级。

第一，用虚拟机和快照。每次测试前恢复到一个干净快照，避免上一次PoC执行留下的堆碎片影响结果。内核利用对初始状态非常敏感，连续多次运行同一个PoC，成功率会因为内存碎片化而明显下降。恢复快照后重新跑，成功率会回到初始水平。

第二，内核编译时开启调试信息。在.config里设置CONFIG_DEBUG_INFO=y，并关闭CONFIG_RANDOMIZE_BASE（仅限调试），可以在内核崩溃时看到更完整的栈回溯。正式调试时建议保留KASLR，以便在真实条件下验证绕过逻辑。

第三，串口日志接出来。在虚拟机里配置串口输出到宿主机文件，内核Oops信息不要只依赖虚拟机的屏幕，否则机器重启后很容易丢失关键日志。比如使用下面的启动参数：

console=ttyS0,115200 ignore_loglevel

然后宿主机用screen /dev/ttyUSB0 115200之类的方式捕获日志。

第四，给系统设置自动重启。在/etc/sysctl.conf里加上kernel.panic_on_oops=1和kernel.panic=5，当利用代码把内核打崩时，机器会在几秒后自动重启，并输出崩溃信息到串口日志。这一步能让反复测试的过程少很多人工干预。

4.3 防御与缓解措施

分析漏洞的根本目的，是帮助防守侧更准确地进行应急响应。针对CVE-2025-21756这类“条件触发+本地提权”漏洞，我建议按优先级做以下事情。

第一优先级，也是最有效的：升级内核到修复版本，或者拉取官方补丁并重新编译/热加载。CVE-2025-21756的修复补丁本身很小，但它的效果是阻断漏洞根因，任何利用链都无法在此基础上继续。不要因为“条件苛刻”就延迟补丁，攻击者往往会在公告发布后立刻开始逆向利用链。

第二优先级：如果无法立即升级，通过权限收敛降低攻击面。检查受限用户是否能加载相关模块，是否具备触发漏洞所需的能力。对于非特权用户，如果业务不依赖用户命名空间，可以设置sysctl kernel.unprivileged_userns_clone=0来关闭非特权创建命名空间，这能封掉部分内核利用的常见前置条件。

第三优先级：启用内核防护机制。确认系统开启了KASLR、SMEP、SMAP，这些机制无法阻止漏洞本身，但会显著提高利用难度，迫使用从“即插即用”变成“手动调exp”。同时，开启SELinux或者AppArmor，即使攻击者拿到了root，如果能正确配置强制访问控制策略，依然能限制敏感文件的读取和写入能力，增加攻击成本。

第四优先级：监控和审计。在syscall层面对可疑的进程行为做hook或审计，重点关注同一进程反复触发unshare、setuid、setresuid这类与权限相关的行为。“利用成功后的行为特征”比“漏洞触发时的行为特征”更容易被检测，因为提权代码最终一定会执行特权凭证变更动作。

4.4 对相似漏洞的延伸思考

把CVE-2025-21756分析透之后，你会发现它代表的是一类问题，而不是孤立的案例。这几年大批内核提权漏洞的根因都指向UAF和对象生命周期管理错误。漏洞公告里写着“use-after-free in xxx”，但真正的可利用点往往不在释放代码本身，而在于释放之后那块内存能不能被重新分配、有没有残留引用让攻击者再次触达。

我自己的经验是，评估一个UAF有没有提权潜力，可以从三个问题入手：

第一，释放的对象是否持有函数指针或重要权限字段。如果是，那利用价值立刻上一个台阶。

第二，对象释放后的kmem_cache是否与某个攻击者可控对象的cache是同一个。如果两个对象大小相同且共用cache，重分配的成功率会非常高。

第三，触发UAF的操作需要什么权限。如果能由普通用户触发，那就是本地提权漏洞；如果必须特权用户触发，那它的危害更多体现在权限提升“之后”的横向扩展上。

这几个问题可以作为以后看CVE的安全研究员“条件反射式”的检查清单，能帮你迅速判断一个漏洞是否值得深入跟踪，而不是被“评级不高”之类的标签误导。

最后分享一个我复现时的细节：利用成功后不要直接关掉shell，先试试把/proc/sys/kernel/randomize_va_space改成0，再重新触发一次UAF，你会发现KASLR绕过那一步的代码可以直接跳过，整体成功率会高很多。这虽然在实际攻击里不可行，但在调试利用链时很有价值，可以帮你快速区分问题是出在“绕过缓解措施”还是“堆布局不稳”上。如果关闭KASLR后仍然失败，问题大概率出在对象重分配环节，而不是随机化处理环节。