pedit COW：一场在页面缓存里悄无声息的 root 政变

2.1 act_pedit 的正常工作流#

tc（traffic control）是 Linux 的流量整形瑞士军刀。其中 pedit action 可以在数据包经过时，实时修改包头字段——比如改 TTL、改 DSCP、改 IP 地址。

当你配置一条 pedit 规则并触发它时，内核调用链大致是：

1
tcf_pedit_act()
2
  → pedit_skb_hdr_offset()    // 计算偏移
3
  → tcf_pedit_act() 内部       // 校验写入范围
4
  → 如果页面是共享的（refcount > 1）
5
      → 创建私有副本 (CoW)
6
  → 写入数据

理想情况下，CoW 保护在写入前完成，shared page 永远不被污染。

2.2 断裂点在哪里？#

问题出在两次偏移解析之间。

第一次校验发生在 tcf_pedit_act() 计算 nkeys 时，它检查所有 key 的 offset、val、mask 组合后的总写入范围是否合法。此时对于某些特殊的 key 类型（偏移在运行时依赖实际数据包头内容才能确定），内核使用的是一种「预留槽」机制——先分配了一个最大范围，但没有精确锁定每个 key 的最终落点。

第二次，也就是实际写入时，这些 key 的偏移被运行时解析（例如基于 VLAN tag 层数动态计算）。如果运行时解析出的偏移超出了第一次校验时预留的私有副本范围——

写入操作就越界落回了共享的 page cache 页。

用一句话讲：

它量好尺寸才去借西装，结果扣子缝歪了，扎到了别人的皮肤上。

2.3 投毒链条#

攻击者的完整攻击链：

1
1. 创建用户命名空间 → 获得 namespace-local CAP_NET_ADMIN
2
2. 加载 act_pedit 模块（如果未加载）
3
3. 打开 /bin/su（setuid root）→ 页面进入 page cache（共享状态）
4
4. 构造 tc pedit 规则，精确计算偏移使写入落在 /bin/su 的内存页中
5
5. 触发规则，向 cached page 注入 shellcode / 修改逻辑
6
6. 执行被投毒的 /bin/su → 内核看到 setuid bit + 文件未修改（磁盘是干净的）
7
   → 实际执行的是被污染的内存页中的代码
8
   → 获得 root shell

精妙之处：它不需要写 /etc/passwd、不需要改 sudoers、不触发任何文件系统级别的审计日志。整个攻击在内存中完成，文件哈希不变，AIDE/Tripwire 静默。

3.1 入口门槛低#

过去的 page-cache 漏洞往往需要特定条件：

• Dirty Pipe 需要 pipe + splice 的配合
• DirtyClone 需要 io_uring 支持

而 pedit COW 的入口是 非特权用户命名空间 + 可加载的内核模块。在主流发行版的默认配置下，这两项都是开启的：

3.2 检测盲区#

传统检测手段几乎全部失效：

• 文件完整性监控（AIDE/Samhain/Tripwire）：磁盘文件未被修改 → 通过
• auditd 文件访问日志：只监控 syscall 层面的 open/read/write → 不覆盖 page cache 操作
• 杀毒软件：无法扫描内核态的内存写入
• EDR/HIDS：除非 hook 了内核函数，否则看不到 tcf_pedit_act 内部的越界写入

唯一有效的检测是行为审计：一个非特权用户突然执行了 tc 命令并带着 pedit action，这本身就是异常信号。但攻击者可以在投毒后清理 tc 规则，痕迹只留在一瞬间。

3.3 时间线令人不安#

1
2026-05-23  补丁出现在 netdev mailing list（标注为"数据损坏修复"）
2
2026-06-16  CVE 编号分配（补丁合入主线）
3
2026-06-17  公开 PoC 发布
4
2026-06-26  The Hacker News 报道
5
2026-06-29  本文发布时，大量发行版仍未推送修复

3 周——从补丁公开到武器化利用。如果一个漏洞的补丁在 mailing list 上躺了三周而无人重视，那它不是被遗忘，而是被忽视了。

4.1 复现环境（PoC 已验证）#

根据公开 PoC 的测试结果：

• RHEL 10：直接提权成功，无任何阻断
• Debian 13 (trixie)：直接提权成功
• Ubuntu 24.04：需通过 AppArmor profile 路由（利用仍可用的 profiles），提权成功
• Ubuntu 26.04：AppArmor 阻断默认 user namespace 创建，exploit 在此环境下失败（但内核本身仍然脆弱）

PoC 地址：github.com/sgkdev/packet_edit_meme

4.2 快速自查#

1
# 1. 检查内核版本
2
uname -r
3

4
# 2. 检查 act_pedit 模块是否可加载（存在 .ko 文件即危险）
5
find /lib/modules/$(uname -r) -name '*act_pedit*'
6

7
# 3. 检查 unprivileged user namespaces 状态
8
# Debian/Ubuntu:
9
cat /proc/sys/kernel/unprivileged_userns_clone
10
# RHEL/CentOS:
11
cat /proc/sys/user/max_user_namespaces
12

13
# 4. 综合判定：
14
#    - 内核版本 < 修复版本（各发行版自行查询）
15
#    - act_pedit 模块可用（.ko 存在或已加载）
16
#    - unprivileged userns = 1（或 max_user_namespaces > 0）
17
#    → 系统存在被利用条件

4.3 立即处置：两条防线，双管齐下#

防线一：阻断 act_pedit 模块加载

1
# 检查模块是否已加载
2
lsmod | grep act_pedit
3

4
# 永 久阻止加载
5
echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf
6

7
# 如果已加载，立即卸载
8
sudo rmmod act_pedit 2>/dev/null

此项操作不影响正常网络功能——除非你主动使用 tc pedit 修改数据包头。绝大多数服务器不需要此功能。

防线二：禁用非特权用户命名空间

1
# Debian/Ubuntu（立即生效 + 持久化）
2
sudo sysctl -w kernel.unprivileged_userns_clone=0
3
echo "kernel.unprivileged_userns_clone = 0" | sudo tee /etc/sysctl.d/99-disable-userns.conf
4

5
# RHEL/CentOS
6
sudo sysctl -w user.max_user_namespaces=0
7
echo "user.max_user_namespaces = 0" | sudo tee /etc/sysctl.d/99-disable-userns.conf

⚠️ 警告：禁用 unprivileged userns 会破坏 rootless 容器（Podman rootless、Docker rootless）、部分 CI 沙箱、以及基于命名空间隔离的浏览器沙箱（Chromium/Firefox）。在生产环境操作前务必评估影响。

防线三：升级内核并重启

这是唯一彻底的修复方案。对于无法立即重启的系统，前两条防线是救命稻草。

1
# Ubuntu/Debian
2
sudo apt update && sudo apt install linux-image-generic -y
3
sudo reboot
4

5
# RHEL/CentOS
6
sudo yum update kernel -y
7
sudo reboot

4.4 事故后的取证思路#

如果怀疑已被入侵：

1
# 1. 检查 tc 规则中是否有异常的 pedit action
2
tc -s filter show dev lo 2>/dev/null
3
tc -s filter show dev eth0 2>/dev/null
4

5
# 2. 清除页面缓存（会丢掉攻击痕迹，但至少确保当前运行的二进制是干净的）
6
echo 3 | sudo tee /proc/sys/vm/drop_caches
7

8
# 3. 检查是否有异常 root shell 进程（如 /bin/su 的不正常子进程）
9
ps auxf | grep -v grep | grep -E 'su|bash.*root'
10

11
# 4. 全面取证：dump 内存、检查 auditd 日志时间线上的 tc 命令
12
#    但因攻击在内存中完成，磁盘取证价值有限。
13
#    原则：发现被利用 → 视为完全失陷 → 重装系统，不是清理。