CVE-2026-46300 Fragnesia提权漏洞有多危险？深度分析与应急指南

Q1：我刚看到新闻说 Linux 内核又爆出一个叫 Fragnesia 的漏洞，这到底是怎么回事？

这两周 Linux 内核真的是焦头烂额，连续被打了三拳。

第一拳是 CVE‑2026‑31431（Copy Fail），CVSS 7.8，algif_aead 模块的本地提权，影响从 2017 年那次性能优化开始就埋下了；
第二拳是 Dirty Frag，同一个研究团队 V12 Security 发现的页缓存污染问题；
第三拳就是你说的 CVE‑2026‑46300（Fragnesia），同样由 William Bowling 和 V12 Security 披露，属于 Dirty Frag 漏洞家族的延伸，目标是 XFRM ESP‑in‑TCP 子系统。

三个漏洞，两周内接连曝光，且都是同一研究团队的成果。这不是巧合，是他们在对内核特定子系统做系统性审计。

Q2：XFRM ESP‑in‑TCP 是什么？普通 Linux 服务器上会跑这个子系统吗？

好问题，这里很多人会有误判。

XFRM 是 Linux 内核的 IPSec 变换框架（Transform Framework），负责处理网络层的加密/解密流量。ESP（Encapsulating Security Payload） 是 IPSec 的一个协议，负责数据包的加密和完整性保护。

ESP‑in‑TCP 是一种把 ESP 数据包封装在 TCP 流里传输的机制，主要用于：

• 企业内网 VPN 场景（Strongswan、Libreswan 等）
• 云厂商的 VPC 间安全隧道
• Kubernetes 节点间加密通信（某些 CNI 插件，如 Cilium 开启 IPSec 模式时）

如果你的服务器上没有跑 IPSec VPN，或者 K8s 集群没有启用节点间加密，这个漏洞的远程利用面几乎为零。

但注意：这是本地提权漏洞，不依赖网络访问。只要攻击者能在你的机器上以普通用户身份执行代码，他就能利用这个漏洞拿到 root。

Q3：它的攻击流程是怎样的？有多难复现？

这个漏洞的可怕之处不在于需要复杂条件，而恰恰相反——它极其稳定，无需竞争条件。

这里是白话版的五步攻击流程：

第一步：创建用户和网络命名空间，获取 CAP_NET_ADMIN 能力

# 普通用户创建命名空间（大多数 Linux 默认允许）
unshare -rUn /bin/bash

第二步：在内核中安装一个 AES‑128‑GCM 加密的 ESP 安全关联（SA）

攻击者使用已知密钥安装一个 SA，为后续的精确控制做准备。

第三步：利用 AF_ALG 接口构建密钥流查找表

// 伪代码示意：构建 256 项查找表
// 将每个可能的密钥流字节映射到对应的 IV nonce
// 这样就能对页缓存的任意字节实施精确的 XOR 替换

第四步：把目标二进制文件拼入 TCP 缓冲区并切换到 espintcp 模式

漏洞的核心在这里：skb（socket buffer）在合并共享页碎片时，忘记了传播 SKBFL_SHARED_FRAG 标记。

内核以为这段内存不是共享的，于是放心地做了原地解密（in‑place decryption）。

结果：AES‑GCM 密钥流直接 XOR 到了 /usr/bin/su 在页缓存中的副本上。

第五步：执行被篡改的 /usr/bin/su，获得 root shell

# 执行被污染的二进制
/usr/bin/su
# 提权成功
id  # -> uid=0(root)

整个流程从普通用户到 root，稳定复现，不需要多次重试。

Q4：等等，你说"页缓存的副本"——那磁盘上的 /usr/bin/su 文件没有被改？

正是。这也是这个漏洞最阴险的地方。

• 磁盘文件完好：/usr/bin/su 的 inode 和磁盘数据没有任何改变
• 只有内存页缓存中的副本被篡改
• 用 sha256sum /usr/bin/su、rpm -V 或者 AIDE 文件完整性检测，全部通过
• 但凡内核调度去执行 su，跑的是内存里那个"毒化"过的版本

这意味着：

1. 重启可以清除：页缓存掉电不持久，重启后恢复正常
2. 手动 drop_caches 也可以：echo 1 > /proc/sys/vm/drop_caches
3. 但如果攻击者在利用后立刻删除工具并维持持久化，你可能完全无法从文件层面发现攻击痕迹

Q5：那怎么知道自己的系统有没有被利用过？能检测吗？

检测思路分两层：

层一：检查是否已被利用（事后取证）

# 1. 检查最近的 root 登录记录
last root | head -20
lastlog | grep root

# 2. 检查异常进程
ps aux | grep -E '(su|sudo|bash|sh)' | awk '$1=="root"'

# 3. 检查 /etc/sudoers 和 /etc/passwd 是否被修改
stat /etc/sudoers
stat /etc/passwd
rpm -qf /etc/sudoers 2>/dev/null || dpkg -S /etc/sudoers 2>/dev/null

# 4. 检查 SSH 授权密钥（攻击者常在这里留后门）
find /root/.ssh /home/*/.ssh -name 'authorized_keys' -exec cat {} \;

# 5. 检查 auditd 日志（如果启用了）
ausearch -m USER_LOGIN,USER_AUTH -ts recent

层二：检查漏洞利用的内核特征

# 检查是否有可疑的 espintcp 套接字操作
cat /proc/net/esp | head -20 2>/dev/null

# 检查是否有用户命名空间创建（利用的必要前提）
grep -i 'unshare\|user_ns' /var/log/audit/audit.log | tail -20

# 检查内核模块加载记录
dmesg | grep -E '(esp|xfrm|ipsec)' | tail -20

如果你启用了 Falco，可以用这条规则检测异常提权行为：

- rule: Fragnesia Exploit Attempt
  desc: Detect potential CVE-2026-46300 exploitation via espintcp user namespace
  condition: >
    spawned_process and
    proc.name in (unshare, nsenter) and
    proc.args contains "U" and
    proc.args contains "n"
  output: "Suspicious namespace creation (user=%user.name command=%proc.cmdline)"
  priority: WARNING

Q6：我们系统需要打补丁吗？各大发行版的修复状态怎么样？

先说结论：能升就升，不能升就做缓解措施。

发行版	修复状态
Fedora 43	✅ 内核 7.0.6 已包含修复
上游内核	✅ 补丁已于 2026‑05‑13 提交至 netdev 邮件列表
Ubuntu 24.04 LTS	⚠️ 官方安全公告尚未发布，建议关注 USN
RHEL 9 / Rocky 9	⚠️ 官方正在评估，建议关注 RHSA
Debian 12	⚠️ 补丁打包进度中
openSUSE	⚠️ 评估中

升级内核（推荐）：

# Ubuntu/Debian
sudo apt update && sudo apt upgrade linux-image-$(uname -r) -y
sudo reboot

# RHEL/Rocky/CentOS
sudo dnf update kernel -y
sudo reboot

# 查看当前内核版本
uname -r
# 查看可用更新
dnf check-update kernel   # RHEL系
apt list --upgradable 2>/dev/null | grep linux-image  # Debian系

Q7：如果暂时不能重启升级，有什么临时缓解方案？

有几个选项，按效果排序：

方案 A：限制用户命名空间创建（强烈推荐）

这是阻断利用链的第一步，利用者必须能创建 User Namespace：

# 方法1：通过 sysctl 禁止非特权用户创建用户命名空间
echo "kernel.unprivileged_userns_clone = 0" >> /etc/sysctl.conf
sysctl -p

# 方法2（内核参数方式，部分发行版）
echo "user.max_user_namespaces = 0" >> /etc/sysctl.conf
sysctl -p

# 验证
cat /proc/sys/user/max_user_namespaces   # 应为 0

⚠️ 副作用提醒：Docker、Podman（rootless 模式）、某些 Chrome/Firefox 沙箱功能依赖用户命名空间，禁用后可能影响这些服务，请先评估影响再操作。

方案 B：如果不使用 IPSec，卸载相关内核模块

# 检查是否在使用 IPSec
ip xfrm state list
ip xfrm policy list

# 如果没有任何输出，可以尝试禁用相关模块
modprobe -r xfrm_user 2>/dev/null
modprobe -r esp6 2>/dev/null
modprobe -r espintcp 2>/dev/null

# 加入黑名单防止自动加载
cat >> /etc/modprobe.d/blacklist-fragnesia.conf << 'EOF'
blacklist espintcp
blacklist xfrm_user
EOF

# 更新 initramfs（部分系统需要）
update-initramfs -u 2>/dev/null || dracut -f 2>/dev/null

方案 C：页缓存清理（发现攻击时的应急处置）

# 强制清理页缓存（需要 root 权限）
sync && echo 3 > /proc/sys/vm/drop_caches

# 最彻底的方式——重启
reboot

Q8：Kubernetes 集群需要特别关注吗？

这是个好问题，很多人忽略了容器环境的影响。

高风险场景：

1. K8s 集群开启了节点间 IPSec 加密（如 Cilium with --enable-wireguard=false --enable-ipsec）
2. 容器运行时配置了 allowPrivilegeEscalation: true
3. Pod 使用了 hostPID: true 或 hostNetwork: true

检查你的Kubernetes 集群：

# 检查是否启用了 IPSec 相关 CNI 配置
kubectl -n kube-system get cm cilium-config -o yaml 2>/dev/null | grep -i ipsec
kubectl -n kube-system get cm calico-config -o yaml 2>/dev/null | grep -i ipsec

# 检查有问题的 Pod 安全配置
kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.hostPID==true or .spec.hostNetwork==true) | .metadata.name'

# 检查特权容器
kubectl get pods --all-namespaces -o json | \
  jq -r '.items[] | select(.spec.containers[].securityContext.privileged==true) | [.metadata.namespace, .metadata.name] | @tsv'

应急加固措施：

# 使用 PodSecurityPolicy 或 OPA Gatekeeper 拒绝特权容器
# PodSecurityAdmission（K8s 1.25+）
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restrict-fragnesia
spec:
  privileged: false
  allowPrivilegeEscalation: false
  hostNetwork: false
  hostPID: false
  volumes:
  - 'configMap'
  - 'emptyDir'
  - 'secret'

节点层面：给所有 Worker Node 的内核快速打上临时缓解措施（限制 user namespace），防止容器逃逸。

Q9：这个漏洞和之前的 Dirty Cow、Dirty Pipe 相比，谁更危险？

这是个很有意思的对比，来一张表：

漏洞	CVE	年份	类型	是否需要竞争条件	稳定性	主要危害
Dirty Cow	CVE‑2016‑5195	2016	本地提权	✅ 需要（竞争）	中等	可写只读内存映射
Dirty Pipe	CVE‑2022‑0847	2022	本地提权	❌ 不需要	高	覆写只读文件页缓存
Copy Fail	CVE‑2026‑31431	2026	本地提权	❌ 不需要	极高	任意页缓存写入
Fragnesia	CVE‑2026‑46300	2026	本地提权	❌ 不需要	极高	借助 ESP 原地解密篡改页缓存

Fragnesia 和 Dirty Pipe 是同一类型的攻击——页缓存污染提权。

区别是 Dirty Pipe 利用的是 splice/pipe 机制，而 Fragnesia 利用的是 ESP‑in‑TCP 的加解密流程。前者补丁打了 4 年还有人没升，后者刚出来，窗口期更危险。

从实际危害看，Fragnesia 的稳定性比 Dirty Cow 高，和 Dirty Pipe 持平，但它依赖 XFRM 子系统，影响面相对 Dirty Pipe 要小一些（不是所有环境都跑 IPSec）。

Q10：好，我现在应该按什么顺序处理这件事？给我一个清单。

直接告诉你操作顺序：

今天（0‑4小时内）：

# Step 1：确认自己系统的内核版本
uname -r
cat /etc/os-release

# Step 2：检查是否在使用 IPSec（如果没有，风险降一级）
ip xfrm state list
ip xfrm policy list

# Step 3：检查是否允许非特权用户创建命名空间
cat /proc/sys/user/max_user_namespaces
# 如果是正数，立即限制
echo "user.max_user_namespaces = 0" >> /etc/sysctl.d/99-fragnesia.conf
sysctl -p /etc/sysctl.d/99-fragnesia.conf

本周内（升级内核）：

# Step 4：申请变更窗口，升级内核
# Ubuntu 用户
sudo apt update && sudo apt upgrade -y
sudo reboot

# RHEL/Rocky 用户
sudo dnf update kernel -y
sudo reboot

持续监控：

# Step 5：开启 auditd 监控可疑的 namespace 创建
cat >> /etc/audit/rules.d/fragnesia.rules << 'EOF'
-a always,exit -F arch=b64 -S unshare -k suspicious_unshare
-a always,exit -F arch=b64 -S clone -F a0&268435456 -k user_namespace
EOF
service auditd restart

总结一句话

CVE‑2026‑46300（Fragnesia）是 2026 年两周内第三个 Linux 内核高危提权漏洞，利用 XFRM ESP‑in‑TCP 原地解密缺陷篡改页缓存实现稳定 root 提权，无需竞争条件；立即行动：限制 user namespace 创建 + 尽快升级内核，K8s 环境额外检查 IPSec 配置和特权容器。