作者：0xShe

CVE-2026-31431 内核提权工具使用指南

0x01 快速上手

由于有的目标环境缺少 Python，使用 C 语言重写了该提权逻辑。

1. 编译

在你的 Linux 机器或 WSL 中运行（建议使用 -static 避免 GLIBC 版本报错）：

gcc -static exploit.c -o exploit

2. 部署与执行

将生成的二进制文件上传到靶机：

chmod +x exploit
./exploit

如果利用成功，程序会自动执行 su 并直接弹回一个 root 权限的 Shell，无需输入密码。

0x02 提权逻辑：它是怎么工作的？

这个 Exploit 利用的是 Linux 内核 AF_ALG 接口（内核加密 API）的一个逻辑缺陷。

1. 创建加密套接字：程序通过 socket(AF_ALG, ...) 创建一个 AEAD（关联数据的认证加密）类型的套接字。
2. 内存注入 (Splice)：利用 Linux 的 splice 系统调用，可以将文件描述符（这里是 /bin/su）的数据流直接导向内核的加密缓冲区。
3. Payload 覆盖：我们在内存中通过特定的偏移量，将 /bin/su 的验证逻辑部分替换为我们的提权 Payload（一段运行 /bin/sh 的微型 ELF 程序）。
4. 触发提权：当内核完成这一系列复杂的“加密”操作后，原本在内存里的 su 已经被篡改。最后执行 system("su") 时，系统运行的是我们篡改后的 root shell。

0x03 踩坑指南：为什么有的会要求输入密码？

在调试过程中，如果程序提示 Exploit finished 但运行 su 依然要密码，通常是以下细节没对上：

1. 致命的 MSG_MORE 标志

这是最容易翻车的地方。在 sendmsg 时，必须带上 MSG_MORE 标志位。

• 原因：这个标志告诉内核“数据还没传完，先别急着关缓冲区”。
• 后果：如果不带这个标志，内核会立即结束当前的加密上下文。此时后面的 splice 注入就无法进入正确的内核缓冲区，篡改也就无从谈起。

2. 关联数据长度 (Assoclen)

内核在处理 AEAD 加密时，对关联数据的对齐和长度检查非常死板。

• 坑点：如果 C 代码里的 ASSOCLEN 设置为 4 字节而实际预期是 8 字节（或者反过来），内核会直接抛出非法参数错误，或者虽然不报错但完全不执行后续的注入逻辑。

3. 文件偏移重置

在循环篡改 /bin/su 的过程中，必须确保每次 splice 都是从文件的 0 偏移开始读。

• 坑点：如果 off_su 没有显式重置为 0，splice 就会像 read 函数一样往后移动指针。第二次循环时注入的数据就会错位，导致 su 程序损坏或逻辑失效。

4. 补丁

有的系统偷偷给你打了补丁，这也是跟朋友测试出来的，有的机器已经自己偷偷上补丁了。

0x04 注意事项

• 内核版本：该漏洞主要针对 5.x 早期版本的内核（如 Ubuntu 20.04 初始版本）。如果内核已经修补，此方法将失效。
• 路径问题：不同发行版 su 的位置不同（/bin/su 或 /usr/bin/su），代码已做自动探测，但如果都不在，需手动 which su 修改。
• 免责声明：本文章只限于技术交流，不得用于任何非法活动，使用工具自行承担相应法律责任。