Linux内核潜伏13年的OVSwrap漏洞曝光：本地普通用户即可提权至root

导语：一个在Linux内核中潜伏长达13年的漏洞，被独立安全研究员阿西姆·马尼扎达公开披露。该漏洞位于内核的Open vSwitch数据通路模块，攻击者无需任何特权，仅凭本地普通账号即可在多种主流Linux发行版上提权至root。公开的概念验证代码（PoC）已附带约800个x86-64内核版本的精确偏移量，覆盖范围之广堪称”武器级”。

来源：本文编译自 The Hacker News 报道《New OVSwrap Linux Kernel Flaw Lets Local Users Gain Root via Open vSwitch》，并参考 CloudLinux 官方安全公告及技术细节。

一、漏洞概述

CVE-2026-64531（代号 OVSwrap）是Linux内核Open vSwitch内核数据通路模块中的一个内存破坏漏洞。该漏洞于2026年7月28日由安全研究员阿西姆·马尼扎达（Asim Manizada）通过oss-security邮件列表正式披露，同时配套发布了完整的PoC和技术分析。

该漏洞的危险性体现在多个层面：

利用门槛极低：无需sudo、无需任何特权、无需OVS预先配置、无需主机级CAP_NET_ADMIN能力
影响范围极广：默认配置的AlmaLinux 9/10、Ubuntu 22.04、Debian 12/13、Fedora 42-44等20余个主流Linux发行版均可被攻击
PoC已公开：附带了约800个x86-64内核版本的预编译偏移记录，几乎涵盖所有主流发行版的近期内核

根据MITRE ATT&CK框架，该漏洞利用对应权限提升（TA0004）战术阶段，是典型的本地提权场景。

二、技术根源：一个13年前的”沉默”BUG

OVSwrap的故事，源于Open vSwitch内核模块中一个长期存在但一直未被利用的编程缺陷。

16位长度字段的设计局限

Open vSwitch将生成的流动作（flow actions）存储为Netlink属性，其nla_len字段宽度为16位，即单个嵌套属性的最大长度上限为65535字节。

从代码层面看，一个不安全的赋值操作早在约13年前就已存在于内核代码中。当时的代码中，一个32 KiB的总生成动作流上限无意中起到了”安全护栏”的作用——它限制了在单个嵌套属性中可累积的动作数量，使其始终低于65535字节的16位字段上限。

2025年的”打开潘多拉魔盒,

2025年3月的一次内核代码变更（commit a1e64addf3ff）移除了这一32 KiB上限，理由是它在大型OpenStack部署中会产生不可预测的失败行为。然而，这一变更的代码审查讨论聚焦于可靠性和用户体验层面，完全忽视了安全层面的连锁后果。

移除护栏后，原本”沉默”13年的赋值缺陷瞬间变为可被利用的真实漏洞。

漏洞触发机制

攻击者向内核提交一个CLONE动作，其内部封装数百个conntrack子动作。在x86-64架构上，内核将每个conntrack动作展开为164字节。当生成的嵌套动作总数超过65535字节时，OVS将该值写入16位nla_len字段——值发生溢出回绕，从65535以上变为一个小数值。

后续代码信任这个被”绕回”的长度值，从攻击者控制的conntrack数据内部恢复解析——而这些数据中早已被预先植入伪造的OVS动作。由于着陆点是同一连续缓冲区内的确定性位置，整个利用过程无需堆内存布局调整。

三原语串联提权

公开PoC利用漏洞引发的回绕错误，串联三个内核原语完成提权：

内核指针泄露：通过伪造的OUTPUT动作实现
任意内核读取：通过伪造的tunnel SET动作实现
目标性减一写入：通过伪造tun_dst指针的拆除操作实现

PoC首先在主机上派生一个辅助进程，然后进入用户命名空间，利用上述原语找到该辅助进程的凭据结构。在现代内核上，将进程的fsuid和fsgid递减至0，相当于获得文件系统层面的root权限。

成功利用后，PoC会修改/etc/sudoers.d/或/etc/sudoers文件，植入提权规则，并启动root shell，同时保留进程和OVS状态以避免触发不安全的清理流程。

三、攻击前置条件与影响范围

虽然漏洞利用门槛低，但仍需满足若干前置条件：

条件	说明
x86-64架构	当前PoC仅针对x86-64构建
OVS内核数据通路模块可用	`openvswitch.ko` 文件存在于`/lib/modules/$(uname -r)/kernel/net/openvswitch/`
启用未授权用户命名空间	系统允许普通用户创建私有用户与网络命名空间
OVS支持conntrack	内核构建时启用`CONFIG_OPENVSWITCH`与conntrack支持
FTP conntrack助手已安装	PoC依赖FTP连接跟踪助手
已安装sudo	用于后续提权操作

关键提醒：即使lsmod输出为空（openvswitch模块当前未加载），系统仍不安全。普通用户通过解析模块的Generic Netlink族名称，可触发内核自动加载该模块。

默认配置可利用的发行版（部分列表）

阿西姆的非穷举测试矩阵显示以下发行版在默认配置下可被攻击利用：

AlmaLinux 9/10、CentOS Stream 9/10、Rocky Linux 9/10
Alpine 3.22-3.24、Arch、Gentoo、Kali 2026.1、Linux Mint 22.3
Amazon Linux 2023、Debian 12/13、Fedora 42-44
NixOS、openSUSE Tumbleweed、Pop!_OS
Ubuntu 22.04

部分缓解的发行版

Ubuntu 24.04：默认AppArmor配置阻断直接命名空间创建，但PoC中的aa-exec -p trinity回退方案可绕过限制
Ubuntu 26.04：默认配置阻断普通用户路径；但若关闭其AppArmor用户命名空间限制，则可被利用

不受影响的发行版

测试显示Amazon Linux 2、Debian 11、Rocky Linux 8和Ubuntu 20.04因保留较旧代码路径，未受此漏洞影响。

四、蓝队视角：应急响应与防御建议

MITRE ATT&CK战术映射

战术阶段	技术编号	描述
TA0004 权限提升	T1068	利用漏洞进行本地提权
TA0007 发现	T1083	文件与目录发现（扫描sudoers等敏感配置）
TA0003 持久化	T1098	账户操控（植入sudoers规则）
TA0008 横向移动	T1078	滥用账户与权限（root后跨账户扩散）

应急处置清单

优先级	操作	说明
紧急	应用内核补丁或临时缓解	立即阻断漏洞利用路径
紧急	排查sudoers配置	检查`/etc/sudoers`与`/etc/sudoers.d/`目录，删除非团队成员添加的条目
高	排查可疑账号与SSH密钥	重点关注root与新增高权限账号
高	检查审计日志	重点关注命名空间创建、内核模块加载、sudoers写入事件
中	排查OVS数据通路模块加载记录	使用`dmesg`和`auditd`日志确认是否有非预期的模块加载
中	评估共享主机风险	多用户/多租户环境下风险等级最高

分层防御方案

第一层（推荐）：阻断模块加载

echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf

关键提示：必须使用install指令而非blacklist。blacklist仅阻止通过/etc/modules-load.d/、udev、hotplug的自动加载，无法阻断内核侧request_module()调用——而这正是本漏洞利用所走的路径。install指令将整个modprobe调用替换为/bin/false，无论从何种路径触发，模块加载都会失败。

第二层（深度防御）：禁用未授权用户命名空间

# RHEL/CentOS/AlmaLinux/Rocky/CloudLinux 9/10
sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/ovswrap.conf

# Ubuntu 22.04
sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' > /etc/sysctl.d/ovswrap.conf

注意：在Ubuntu上，apparmor_restrict_unprivileged_userns并不能缓解此漏洞——CloudLinux团队已实测验证，必须使用上述sysctl设置彻底禁用。

兼容性提醒：禁用未授权用户命名空间会影响rootless Docker/Podman、Kubernetes rootless模式、Snap/Flatpak沙箱以及Chromium/Firefox沙箱。典型共享主机负载不受影响（cPanel、Plesk、DirectAdmin及常规网站）。

第三层：等待并部署内核补丁

已修复的上游内核版本：5.15.212、6.1.178、6.6.145、6.12.97、6.18.40、7.1.5
阿里云、腾讯云等云服务商通常会在1-2周内提供修复内核
内核热补丁（KernelCare、kpatch、livepatch等）可提供无重启修复
升级完成后，记得清理临时缓解：rm /etc/modprobe.d/ovswrap.conf

入侵检测规则建议

内核模块加载监控：

-w /sbin/modprobe -p x -k modules
-w /bin/modprobe -p x -k modules

Syscall层面的命名空间创建监控：监控unshare系统调用，识别带有CLONE_NEWUSER和CLONE_NEWNET组合的异常调用。

sudoers文件完整性监控：使用AIDE、OSSEC等主机完整性监控工具，对/etc/sudoers和/etc/sudoers.d/建立基线，实时告警文件变更。

内核审计规则示例：

# 监控openvswitch模块加载
-w /lib/modules/$(uname -r)/kernel/net/openvswitch/ -p wa -k ovs_module
# 监控sudoers变更
-w /etc/sudoers -p wa -k sudoers_change
-w /etc/sudoers.d/ -p wa -k sudoers_change

五、共享主机场景：风险倍增效应

OVSwrap在共享主机环境下的危险性尤为突出。

正如CloudLinux在其安全公告中所指出的：在共享服务器场景下，”本地用户”绝不仅仅意味着受信任的员工或客户。任何通过过时的CMS插件、网站应用漏洞攻陷一个站点的攻击者，都可能成为本地用户——而OVSwrap正是把这种”单站点沦陷”问题升级为”整服务器沦陷”问题的关键一步。

完整的攻击链清晰而残酷：

一个网站被攻陷（过时的插件或CMS漏洞让攻击者获得单账号代码执行权限）
内核自动加载openvswitch模块（一次Generic Netlink探测即可触发，无需sudo，无需任何特权）
攻击者获得私有命名空间内的CAP_NET_ADMIN能力（通过unshare创建用户与网络命名空间）
恶意流动作触发漏洞，权限提升至root
跨账户扩散：root权限可访问服务器上所有其他账户的文件、数据库、凭据与备份

应用模块阻断或热补丁后，第2步即告失败，攻击链在此中断。原本的”单站点沦陷”维持为”单站点沦陷”——清理范围从一个站点变为一个站点，而非重装整台服务器并启动客户告知流程。

六、防御者的反思

OVSwrap给安全行业留下了几点重要启示：

长期潜伏不等于不存在。一个13年前就存在于代码中的缺陷，仅因一次看似无害的”修复”动作（移除32 KiB上限）就变为可利用漏洞。这再次印证了蓝队防御的核心原则——假设漏洞已经存在，重点在检测与响应。

内核级漏洞的攻击门槛正在降低。配套PoC覆盖800余内核版本的事实说明，攻击者无需复杂调试即可对绝大多数目标完成利用。传统的”等补丁、等运维窗口”模式已无法应对此类公开武器化漏洞。

防御纵深不是空话。模块阻断、命名空间限制、内核热补丁、内核补丁四层防御可叠加部署，单一防御层失效也不会导致完全失守。CloudLinux的KernelCare热补丁无重启修复、CloudLinux 9/10/Ubuntu 22.04已全部覆盖，就是”纵深防御”理念的最佳实践。

七、总结

CVE-2026-64531（OVSwrap）是近年Linux内核领域影响范围最广、利用门槛最低的本地提权漏洞之一。它利用了一条13年前就存在的代码缺陷，借助2025年的一次”善意修复”完成了武器化。普通本地用户无需任何特权即可提权root，公开PoC覆盖800余内核版本，使其成为共享主机、云服务器等多用户环境下必须紧急处置的高危漏洞。

对于运维团队，首要动作是部署模块阻断（install openvswitch /bin/false），次要动作是禁用未授权用户命名空间，根本解决则是等待并部署上游或厂商修复内核。在补丁可用之前，多层防御的组合部署能将风险控制在可接受范围内。

参考资料：