最近安全圈被一枚 Linux 内核漏洞搅得不太平静。编号 CVE-2026-31694 的这个问题，本质上是 FUSE 文件系统子系统里的一处页面缓存溢出缺陷。研究人员不仅把技术细节抖了个干净，连能直接用的 exploit 代码也一并扔到了 GitHub 上。这意味着什么？意味着只要攻击者能在你的机器上执行本地代码，哪怕是个最不起眼的普通账户，也有机会一路飙升到 root，把整个系统的控制权攥在手里。
这个漏洞的杀伤力在于它的"门槛"实在太低。攻击者不需要预先拿到任何特殊权限，不需要复杂的网络渗透铺垫，甚至连 sudo 都用不上。只要系统允许挂载 FUSE 文件系统------而绝大多数桌面发行版和容器环境默认就是这么配置的------攻击者就能借助 fusermount3 或者非特权用户命名空间，轻松搭起一个恶意 FUSE 服务端，然后静等内核往坑里跳。
为什么容器和共享服务器要格外警惕
本地权限提升向来是攻击者眼里的"硬通货"。拿到 root 之后，横向移动、持久化后门、数据窃取这些后续操作才能铺展开来。CVE-2026-31694 的特殊之处在于，它把本地攻击面撕开了一个相当大的口子。桌面环境自不必说，很多容器镜像为了用户体验，并没有严格限制 FUSE 挂载能力；共享服务器上如果多个用户共用内核，一旦有个租户动了歪心思，其他租户的数据和进程都暴露在风险之下。
SUSE 安全团队已经把这个问题定级为"重要"。虽然截至目前，还没有公开报道确认该漏洞已被大规模野外利用，但 exploit 代码一旦公开，防御方的窗口期就被急剧压缩。攻击者向来偏爱这种无需网络立足点的本地提权漏洞，因为内网横向移动时，它们往往就是打通最后一公里的那把钥匙。
漏洞的底层逻辑：一次信任边界崩塌
要理解这个漏洞怎么来的，得先简单过一遍 FUSE 的工作方式。FUSE 全称 Filesystem in Userspace，它的设计初衷是让普通用户不用写内核模块，也能在用户空间实现自定义文件系统。内核在这里扮演"客户端"角色，当用户程序读取目录时，内核会向用户空间的服务端请求目录项数据。如果启用了 readdir 缓存，内核会把这些条目暂存在页面缓存里，下次再访问就能快一些。
问题就出在这个缓存机制上。内核规定每个目录项记录必须能塞进一个 4 KiB 的物理页面。这个约束本身没问题，但代码在把数据复制进页面缓存之前，压根没做边界校验。目录项的序列化长度直接取决于文件名长度，而文件名长度又是 FUSE 服务端说了算。内核盲目信任了服务端的计算结果，没有二次核查。
于是恶意服务端完全可以构造一个长达 4095 字节的文件名。这个文件名经过序列化后，会变成一条 4120 字节的记录。内核二话不说把它往 4096 字节的页面里塞，直接导致 24 个字节溢出到了相邻的内核页面。这 24 个字节是攻击者完全可控的，它们会覆盖掉旁边缓存页里的数据。如果旁边恰好缓存着某个特权二进制文件的关键结构，攻击者就能篡改文件内容，最终诱导内核执行恶意代码，一个 root shell 就这样到手了。
从披露到武器化：时间线并不乐观
这个漏洞的完整利用链由 Bynar 安全团队率先梳理清楚，他们发布的研究报告把每一步的内存布局、溢出偏移、缓存污染策略都讲得相当透彻。几乎在同一时间，GitHub 上出现了可编译运行的 exploit 程序，验证了这个本地提权路径的可靠性。另一位独立安全研究员也放出了自己版本的 root exploit，进一步坐实了 CVE-2026-31694 不是停留在纸面上的理论风险，而是实打实能弹 shell 的实战武器。
不过 CISA 的已知被利用漏洞目录（KEV）里暂时还没有它的身影，公开利用评级目前也维持在较低水平。但这并不能让系统管理员松口气------历史反复证明，exploit 代码公开后的几周到几个月内，往往是野外利用的高发期。防御者最好把这段时间当作"危险窗口期"来对待，而不是"安全缓冲期"。
受影响版本梳理：4 KiB 页面是重灾区
漏洞代码位于内核源码 fs/fuse/readdir.c 的缓存路径里。追溯提交历史，readdir 缓存功能早在 2018 年就已经合入主线，但当时的代码形态还不足以被利用。直到 2025 年某次缓冲区相关的改动之后，这个陈年缺陷才真正具备了武器化条件。按照 Bynar 团队的分析，实际风险大约从 Linux 6.16-rc1 附近开始显现。独立漏洞跟踪器也把影响范围标记到了 7.1 候选版本。
实测环境上，研究人员在 Ubuntu 26.04 镜像里成功拿到了 root shell。这里有个关键的分界线：只有使用 4 KiB 内存页的系统才会中招。如果你的服务器架构采用大页内存（比如 16 KiB 或 64 KiB），这个溢出路径因为页面容量足够大，暂时不会触发。但别因此掉以轻心，绝大多数 x86 桌面和服务器默认都是 4 KiB 页，ARM 服务器也有不少沿用这个配置的。
修复与缓解：打补丁是正道，临时加固也有招
上游维护者的修复思路非常直接：在复制目录项记录之前，加一道简单的边界检查。如果序列化后的记录长度超过一页，直接拒绝写入。这个补丁已经合并到 Linux 主线以及多个稳定版本分支，各大发行版的安全更新也在陆续推送。
对于运维人员来说，最优先的动作永远是升级内核。尤其是跑容器的主机，本地攻击面本来就比物理机大得多，补丁的优先级应该往前提。如果暂时没法重启或者更新内核，也有几条临时缓解措施可以考虑：
先把 FUSE 的使用范围收紧。检查一下系统里有没有业务确实依赖 FUSE，没有的话直接限制挂载能力。对于 fusermount3 这个工具，如果它带着 setuid 位，攻击者就能借助它完成挂载操作。把未使用系统上的 setuid 位去掉，能砍掉一条利用路径。另外，非特权用户命名空间也是现代内核里一个经常被滥用的特性，限制普通用户创建新的命名空间，同样能缩小攻击面。
写在最后
CVE-2026-31694 再次提醒我们，内核子系统里那些"看起来无害"的缓存优化，往往藏着最致命的漏洞。FUSE 的设计哲学是把文件系统逻辑推到用户空间，这本身没问题，但内核在接收用户空间数据时如果丢掉戒心，边界检查缺位，信任边界就瞬间崩塌。对于企业环境来说，这个漏洞的修复不应该只停留在"打补丁"层面，更要借机审视一下 FUSE 和用户命名空间的开放策略------很多时候，默认开启的便利功能，正是攻击者最趁手的跳板。