针对 CVE-2026-74580 (Vghost) 的 Linux 内核权限审计与加固实践

CVE-2026-74580（Vghost）的排查重点，不是简单确认服务器上是否存在 /dev/kvm，而是确认本地用户能否接触虚拟化相关设备节点，以及当前内核是否已经获得发行版提供的修复。公开资料将该漏洞描述为 linux 内核 vhost 子系统中的缺陷：本地攻击者可能在 IOTLB 已连接时，通过特定 ioctl 重新配置虚拟环（vring）。因此，设备节点权限是降低暴露面的措施，但不能替代内核更新，也不能仅凭 /dev/kvm 的权限判断主机是否已经修复。

先确认漏洞范围，不要把 /dev/kvm 当成唯一指标

现有资料明确指向 vhost 子系统和虚拟环重配置路径，但没有提供 Ubuntu 或 Amazon linux 2023 的统一修复版本，也没有证明 /dev/kvm 本身就是该漏洞的唯一入口。实际排查时，应把 /dev/kvm 作为虚拟化权限审计的一部分，同时检查系统中是否存在其他虚拟化和 vhost 相关设备节点。

先记录发行版、内核和设备节点状态：

cat /etc/os-release
uname -a
uname -r

printf '%sn' '--- virtualization-related device nodes ---'
find /dev -maxdepth 1 ( -name 'kvm' -o -name 'vhost*' ) -ls 2>/dev/null

printf '%sn' '--- loaded modules ---'
lsmod | grep -E '(^|[[:space:]])(vhost|kvm)' || true

lsmod 没有匹配项，并不代表系统完全不存在相关能力，因为模块可能尚未加载，也可能由其他服务按需加载。相反，发现 kvm 或 vhost 模块，也不能直接说明系统易受攻击，最终仍要以发行版安全公告和已安装内核的修复状态为准。

Red Hat 的漏洞描述明确提到，利用条件涉及本地攻击者、vhost 子系统、IOTLB 和特定 ioctl。Ubuntu 的 OSV 条目则提供了对应的 Ubuntu 安全漏洞记录。对于 Amazon linux 2023，搜索到的 ALAS2023-2026-1753 摘要对应的是另一个漏洞，不能把它当成 CVE-2026-74580 的修复依据。管理员应继续在本发行版的安全公告中核对 CVE 编号、受影响内核和修复内核。

检查 /dev/kvm 及相关节点权限

先查看传统 Unix 权限、扩展 ACL 和所属用户组：

stat -c '%A %a %U:%G %n' /dev/kvm /dev/vhost* 2>/dev/null

getfacl -p /dev/kvm 2>/dev/null
getfacl -p /dev/vhost* 2>/dev/null

getent group kvm
getent group libvirt 2>/dev/null

重点关注以下几类情况：

• 设备节点是否对“其他用户”开放写权限；
• 节点是否属于一个包含普通登录用户的用户组；
• 是否存在扩展 ACL，导致传统权限位看起来收紧，但某些用户仍然拥有读写权限；
• /dev/kvm 或 vhost 相关节点是否被错误设置为全局可写；
• 节点权限是否由 udev 或虚拟化服务动态生成，重启后可能恢复原状。

随后检查当前登录用户及服务账号的组成员关系：

id
id 用户名

for user in $(getent passwd | cut -d: -f1); do
    groups "$user" 2>/dev/null | grep -E '(^|[[:space:]])(kvm|libvirt)([[:space:]]|$)' 
        && echo "matched: $user"
done

如果主机不需要为普通用户提供虚拟机创建或管理能力，应重点清理不必要的 kvm、libvirt 等组成员。删除组成员前，要先确认该账号不是虚拟化平台、构建任务或其他业务服务的必要运行账号。修改组成员后，已有登录会话通常不会立即失去旧的组凭据，应要求用户重新登录，必要时重启对应服务。

还可以检查设备当前是否被进程打开：

fuser -v /dev/kvm 2>/dev/null
fuser -v /dev/vhost* 2>/dev/null

lsof /dev/kvm /dev/vhost* 2>/dev/null

这一步不能判断进程是否利用了漏洞，但能帮助管理员识别哪些服务确实依赖这些节点。对生产环境直接收紧权限之前，先保留进程、服务和账号对应关系，避免把虚拟机管理服务或关键业务任务一并中断。

Ubuntu 与 Amazon Linux 2023 不要套用同一组权限假设

不同发行版、镜像和云平台初始化方式，可能为设备节点设置不同的用户组、权限位和动态规则。即使两台主机都显示为 Linux，也不能假设它们都使用相同的节点属主或相同的虚拟化服务。

建议分别在 Ubuntu 和 Amazon Linux 2023 主机上保存以下结果，再进行对比：

{
    date
    cat /etc/os-release
    uname -r
    stat -c '%A %a %U:%G %n' /dev/kvm /dev/vhost* 2>/dev/null
    getfacl -p /dev/kvm /dev/vhost* 2>/dev/null
    getent group kvm
    getent group libvirt 2>/dev/null
    lsmod | grep -E '(^|[[:space:]])(vhost|kvm)' || true
} | tee /var/tmp/virtualization-permission-audit.txt

对比时不要只看权限数字。例如，一台主机可能显示为 root:kvm 且权限为组可读写，另一台主机可能使用不同的属组；也可能有 ACL 覆盖基本权限。正确做法是先确认发行版原本的设计，再根据实际业务需求缩小授权范围，而不是为了得到相同的权限字符串，直接对两类系统执行同一条 chmod 命令。

如果节点权限由规则动态生成，手工执行 chmod 只能解决当前状态。应进一步检查设备管理规则和相关服务配置，确认权限在重启、模块重新加载或虚拟化服务启动后仍然符合预期。

通过用户组限制本地访问权限

对不需要使用 KVM 或虚拟化管理能力的普通账号，最直接的措施是移除不必要的特权组成员：

sudo gpasswd -d 用户名 kvm
sudo gpasswd -d 用户名 libvirt

执行前先确认组确实存在，且用户确实属于该组：

getent group kvm
id 用户名

如果设备节点被错误设置为全局可写，应先记录当前状态，再按照发行版默认策略恢复属主和权限。下面的命令仅适用于管理员已经确认系统应使用 root:kvm 且允许组成员访问的场景：

sudo chown root:kvm /dev/kvm
sudo chmod 0660 /dev/kvm

不要把这两条命令直接套用到所有主机。某些系统可能使用不同的用户组，或者通过专门服务管理节点权限。对于 /dev/vhost*，同样应先查看实际节点、属主和动态规则，再决定是否收紧权限，不能因为文件名包含 vhost 就批量修改整个目录。

更稳妥的权限目标通常是：设备节点由系统管理员或受控服务账号拥有，普通用户不具备写权限，只有确实承担虚拟机管理职责的账号进入对应用户组。若业务只需要查看状态而不需要操作设备，也不要默认授予读写权限。

检查并谨慎使用内核参数

内核参数不能凭空替代 CVE 修复。当前资料没有给出 CVE-2026-74580 对应的通用参数名、推荐值或适用于 Ubuntu 与 Amazon Linux 2023 的统一配置，因此不要自行编造类似“关闭某个 vhost 参数即可修复”的结论。

可以先审计当前内核参数中是否存在与虚拟化、IOMMU 或设备访问相关的配置：

sysctl -a 2>/dev/null | grep -Ei 'vhost|kvm|iommu|virt|io'

如果发行版安全公告明确给出了针对该漏洞的参数或模块配置，应以公告中的参数名和值为准，并先在测试主机验证。持久化配置可以采用以下流程：

sudo install -m 0644 /dev/null /etc/sysctl.d/99-local-virtualization-hardening.conf
sudo editor /etc/sysctl.d/99-local-virtualization-hardening.conf

配置文件中只能填写厂商公告明确要求的参数，例如：

# 仅填写发行版安全公告明确给出的参数和值
# 参数名=值

保存后，使用发行版提供的 sysctl 加载方式应用配置，并复核实际值：

sudo sysctl --system
sysctl -a 2>/dev/null | grep -Ei 'vhost|kvm|iommu|virt|io'

如果公告要求更新内核，则应优先完成内核更新和重启，而不是把未注明用途的参数作为替代方案。参数调整可能影响虚拟机启动、网络虚拟化、设备直通和 I/O 行为，生产环境必须先确认运行中的虚拟化工作负载。

不需要虚拟化时，减少相关组件暴露面

如果服务器没有运行虚拟机、容器运行时不依赖相关能力，也没有业务需要访问 KVM 或 vhost 设备，可以从服务和模块两个层面确认是否能够关闭相关组件。先找出使用者：

ps -ef | grep -E '[q]emu|[k]vm|[v]host|[l]ibvirt'
systemctl list-units --type=service --state=running | grep -Ei 'virt|qemu|kvm'

确认没有依赖后，再按照该发行版和业务服务的标准停用流程处理。不要在仍有虚拟机或网络虚拟化任务运行时直接卸载模块，也不要通过粗暴禁用内核模块来代替漏洞修复。对于云主机，是否能够使用 KVM 还可能由宿主机和实例类型决定，客体系统看到的设备节点并不一定代表完整的虚拟化控制能力。

建立一次性修复后的复核清单

完成更新和权限调整后，至少复核以下项目：

uname -r
stat -c '%A %a %U:%G %n' /dev/kvm /dev/vhost* 2>/dev/null
getfacl -p /dev/kvm /dev/vhost* 2>/dev/null
getent group kvm
getent group libvirt 2>/dev/null
lsmod | grep -E '(^|[[:space:]])(vhost|kvm)' || true

然后用一个不应具备虚拟化权限的普通账号重新登录，确认其组成员和设备访问结果：

id
test -r /dev/kvm && echo "readable" || echo "not readable"
test -w /dev/kvm && echo "writable" || echo "not writable"

“不可写”只是权限层面的结果，不代表漏洞已经修复；“节点不存在”也不代表内核一定安全。最终判断应同时满足三个条件：发行版公告确认当前内核已包含修复、非必要账号不再拥有设备访问权限、主机上的虚拟化服务和节点权限在重启后仍保持预期状态。

可供核对的安全资料包括 Ubuntu 的 CVE-2026-74580 OSV 记录 和 Red Hat 对 CVE-2026-74580 的漏洞描述。如果本机使用 Amazon Linux 2023，应以该发行版针对同一 CVE 的安全公告和已安装内核状态为最终依据，不要用其他 CVE 的 ALAS 条目替代判断。