Qualys曝RefluXFS高危漏洞：XFS文件系统暗藏九年“后门“，千万Linux服务器面临root提权风险

Qualys曝RefluXFS高危漏洞：XFS文件系统暗藏九年"后门"，千万Linux服务器面临root提权风险

7月22日，Qualys安全团队对外公布了一则足以让Linux运维人员彻夜难眠的消息——代号RefluXFS的内核漏洞正式浮出水面，CVE编号CVE-2026-64600。这不是那种需要复杂远程渗透才能触发的"高级威胁"，而是一个本地普通用户随手就能点着的"火药桶"。据Qualys估算，全球范围内可能有超过1640万台运行XFS文件系统的设备正暴露在风险之下。

更让人意外的是，这个漏洞最初竟是由AI模型发现的。Qualys在公告中透露，他们使用Anthropic的Claude Mythos Preview对Linux内核进行定向扫描，在多次迭代后模型精准锁定了XFS reflink路径中的竞争条件，并生成了完整的root提权概念验证。AI找漏洞已经不是新闻，但找到这种潜伏九年、影响面如此之广的内核级缺陷，确实给整个行业敲响了警钟。

为什么这次不是"虚惊一场"

XFS作为Red Hat Enterprise Linux及其衍生发行版的默认根文件系统，承载着无数企业核心业务的命脉。从RHEL 8到RHEL 10，从Oracle Linux到Amazon Linux 2023，再到Fedora Server，几乎整个红帽生态都建立在XFS之上。Qualys将其标记为紧急优先级，原因很直白：任何拥有本地shell的普通用户，都能借助这个漏洞把权限提升到root。

这里有个细节值得注意。自2019年xfsprogs 5.1.0版本起，reflink功能就成了mkfs.xfs的默认配置。这意味着近三年新部署的系统，只要根分区是XFS格式，大概率已经打开了这扇"暗门"。Debian、Ubuntu和SUSE虽然默认不用XFS，但如果管理员在安装时手动选择了XFS并启用了reflink，同样会中招。RHEL 7倒是幸免于难，因为其内核3.10压根不支持XFS reflink特性。

攻击原理：一次"写错地方"的磁盘操作

要理解RefluXFS的狡猾之处，得先明白XFS的reflink机制。简单来说，当你用cp --reflink克隆文件时，系统不会真的复制数据，而是让新文件和原文件指向磁盘上的同一块物理区域，只在引用计数里记一笔。只有当某个文件被写入时，内核才会触发copy-on-write（CoW），把修改写到新分配的私有块上，保证原文件不受影响。

漏洞就出在这个"保证"上。

攻击者会先reflink克隆一个受保护的文件——比如/etc/passwd或者某个SUID root二进制文件——到自己拥有写权限的临时目录。然后对克隆文件发起两次并发的O_DIRECT直接I/O写入。第一次写入时，内核在xfs_reflink_allocate_cow()里为了申请事务资源，不得不临时释放inode锁（ILOCK）。就在这个极其狭窄的时间窗口里，第二次写入完成了完整的CoW流程：分配新块、写入数据、重映射extent、把原共享块的引用计数从2减到1。

当第一次写入重新拿到锁后，它手里还攥着释放锁之前获取的物理块地址X。它去查引用计数树，发现X的计数确实是1（因为第二次写入已经解绑了），于是判定"这块已经是私有的，可以直接原地写入"。但它没意识到，这个块X现在只属于原文件了。结果就是，攻击者通过自己拥有的克隆文件，把数据直接写进了原文件的物理块。

更阴损的是，这种写入发生在块设备层，绕过了常规的文件系统审计路径。目标文件的inode元数据——权限、所有者、修改时间、文件大小——纹丝不动。SUID位照样挂着，系统日志里干干净净，连重启都抹不掉这个改动。Qualys在Fedora Server 44和RHEL 10.2上的测试表明，利用这个原理修改/etc/passwd清空root密码，通常只需几秒钟就能跑通。

你的安全加固可能白做了

很多管理员看到这儿可能会想：没关系，我有SELinux、KASLR、SMEP、SMAP，还有容器隔离。抱歉，这些在RefluXFS面前基本形同虚设。

Qualys的测试报告写得很清楚：SELinux在强制模式下未能拦截利用路径。KASLR、SMEP、SMAP这些内存防护机制针对的是内核空间代码执行和指针篡改，而RefluXFS玩的是合法的文件系统I/O操作，根本不走那条路。容器限制也一样失效——只要容器里的普通用户能访问宿主机的XFS文件系统，这个边界就被打破了。

这其实是近年来Linux内核漏洞的一个共同趋势。从Dirty COW到Dirty Pipe，再到现在的RefluXFS，攻击者越来越擅长利用内核子系统之间的"默契盲区"——那些为了性能而共享的缓冲区、extent映射、引用计数，在并发场景下稍不留神就会变成权限提升的跳板。

现在该做什么

好消息是，上游修复补丁已经在7月16日由Linus Torvalds合并进Linux内核主线（commit 2f4acd0）。坏消息是，Qualys明确表示目前没有靠谱的临时缓解措施。SystemTap或kprobe方案虽然能拦截reflink操作，但属于非官方应急手段，生产环境贸然部署可能引发稳定性问题，而且需要厂商背书。

所以最务实的做法就两条：

第一，立刻检查你的系统是否中招。在终端执行xfs_info / | grep reflink=，如果返回reflink=1，且内核版本在4.11以上、未打补丁，那就是高危状态。别忘了检查所有挂载的XFS分区，不只是根分区。

第二，升级内核并重启。这是Qualys认定的唯一可靠修复方式。各发行版正在把补丁向后移植到稳定分支，RHEL、CentOS Stream、Rocky Linux、AlmaLinux、Oracle Linux、Amazon Linux和Fedora的用户需要紧盯各自厂商的安全公告。修复完成后必须重启，因为漏洞涉及内核态的extent映射逻辑，热补丁难以覆盖。

对于暂时无法重启的关键业务系统，可以考虑把敏感工作负载迁移到已修复的节点，或者限制不可信用户的本地登录和shell访问。但这些只是权宜之计，不能替代内核更新。

写在最后

RefluXFS的披露时机颇为微妙。就在几天前，Linux内核项目组在24小时内集中发布了440个CVE公告，创下历史纪录，其中不少同样由AI辅助发现。当AI开始以这种效率和精度扫描内核代码，传统的人工审计模式显然已经力不从心。对企业而言，这意味着漏洞窗口期在缩短，响应速度必须跟上。

九年时间，这个缺陷躺在内核里安然无恙，直到一次AI辅助的代码审查才把它揪出来。它提醒我们：再成熟的文件系统实现，在并发和锁机制的交叉地带，依然可能藏着致命的逻辑裂缝。对于手握XFS服务器的运维团队来说，这个周末大概不会太平了。