加载失败
这是 CVE-2026-31431，一个 Linux kernel 的 local privilege escalation 漏洞，核心落点在 AF_ALG（Linux 内核向用户态暴露 crypto API 的 socket 接口）和 `algif_aead` 路径。公开 PoC 通过污染可读文件的 page cache，把 `su` 这类 SUID 程序改成执行 shell，因此在受影响系统上能直接拿到 root。评论里补充了 AF_ALG 的历史用途：早年用于硬件加速、嵌入式系统和 key 隔离，但在今天很多人看来它扩大了 attack surface。补丁已经进入主线并被不少发行版 backport，但 iwd（Intel Wireless Daemon）等少数组件还依赖它，所以是否能彻底关闭要看具体工作负载和发行版配置。
不少人已经在 Ubuntu、Debian、Arch、Gentoo 等环境里实测，确认 PoC 能把普通用户一路打到 root。看起来脚本默认盯着 `su`，但真正危险的是它能污染可读文件的 page cache，把任意本来只读的内容改成攻击者想要的东西。评论里还提到，它未必只影响 `su`，`/etc/passwd`、共享库、cron 任务和其他 root 会读取的文件都可能成为落点。对共享主机、CI runner、HPC 节点和多人服务器来说，这种 local root 风险显然不是小问题。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
一派观点认为 AF_ALG 是很老的接口，暴露了过大的 attack surface，而且对大多数用户态程序根本没必要。支持者则解释它曾用于硬件加速、低内存嵌入式系统，以及把 key material 留在 kernel 里的隔离需求，`kernel keyring` 也是一条常见理由。折中意见是，即便保留，也应该大幅收窄能力范围，比如限制到特定算法、要求能力位，或者至少别把像 `authencesn` 这种 IPsec 细节直接暴露给用户态。争论核心不是“要不要 crypto”，而是“这个用户态入口到底该有多大”。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
最实用的话题是怎么马上挡住它：黑名单 `algif_aead`、关闭 `CONFIG_CRYPTO_USER_API_*`，或者用 `seccomp`、systemd 的 `RestrictAddressFamilies=` 直接阻止 AF_ALG socket。有人验证了 `install algif_aead /bin/false`、`rmmod`、甚至 `initcall_blacklist=algif_aead_init` 都能让 PoC 失效，但如果功能被编进内核成 `=y`，就不能靠 modprobe 解决。版本上，主线修复点被反复查到落在 6.18.22、6.19.12 和 7.0，发行版则大量依赖 backport，所以不能只看上游版本号。一个现实阻碍是 iwd 依赖 `CONFIG_CRYPTO_USER_API_AEAD`，所以通用发行版没法一刀切全关，只能先修依赖再谈彻底禁用。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
很多人先被页面风格绊住了：文案像 AI 生成，结构松散，还出现了不存在的 `RHEL 14.3` 这种明显幻觉。有人认为这是在借 `copy.fail` 域名和联系表单给 Xint Code 做营销，把安全研究和产品宣传绑在一起；也有人觉得给重大漏洞起名字、单独建站本来就是老传统。争议点不在于能不能宣传，而在于这种低质包装会不会让读者先对内容失去信任。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
这份 PoC 因为强调“732 bytes”而引发大量争论，很多人觉得把 byte count 当卖点本末倒置。有人把压缩 blob 反解成更容易读的 Python 或 C，说明核心其实是 `splice()`、AF_ALG 和 page cache 的组合，不是什么玄学。另一边则认为 exploit 代码不是企业代码，能证明漏洞真实就够了，但即便如此，也不该故意把意图藏在压缩 payload 里。争论实质上是：PoC 应该优先可审计，还是优先极简和炫技。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]
不少评论在问它能不能打穿 rootless Podman、Kubernetes、CI runner 或 shared hosting，结论通常是 PoC 不能直接跨 user namespace，但底层任意写可读文件的能力仍可能被改造成更通用的逃逸链。Android 方面，大多被 SELinux policy 和内核裁剪挡住，AOSP / GrapheneOS 默认通常不暴露 AF_ALG；Qubes OS 则被拿来当隔离做得更彻底的反例。也有人提醒 `allowPrivilegeEscalation=false`、`seccomp`、`no_new_privs` 和 user namespaces 只能缩小 blast radius，真正的节点内核补丁仍然是关键。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]
发行版最初把它标成 medium 或 fix deferred，引发不少人质疑，因为按它们自己的标准，local root privilege escalation 应该算 high。随后相关页面又陆续改成 high / affected，说明各家在重新评估风险。另一条线是披露是否协调：有人说只通知了 kernel security team，没同步 distro，导致各家现在仓促补救；也有人认为 Linux 上游一直把大多数 kernel bug 当作安全问题，本来就不按传统 CVE 流程处理。威胁模型也被反复提醒：单机桌面上的本地漏洞，和共享主机、HPC、shell-as-a-service、build farm 上的同类漏洞，严重性完全不是一个量级。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
AF_ALG: Linux 内核的 socket 接口，把内核 crypto API 暴露给用户态。
algif_aead: AF_ALG 的 AEAD 相关内核模块，漏洞触发主要经过这里。
page cache: 文件背后的内核缓存层；这次攻击利用它污染可读文件内容。
setuid: Unix 可执行位，允许程序以文件所有者的权限运行，常被用来提权。
seccomp: Linux syscall 过滤机制，可用来阻止 AF_ALG 等危险调用。
user namespaces: Linux 的命名空间隔离机制，常用于 rootless 容器和权限降级。
kernel keyring: 内核管理的密钥存储机制，用于尽量减少密钥暴露在用户态内存中。
LPE: local privilege escalation，本地提权漏洞，目标通常是从普通用户升到 root。