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-writeCoW把修改写到新分配的私有块上保证原文件不受影响。漏洞就出在这个保证上。攻击者会先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如果返回reflink1且内核版本在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服务器的运维团队来说这个周末大概不会太平了。