Linux 本地提权漏洞怎么用 `uname -r` 排查？

假设登录的是一台龙蜥 Anolis OS 8 ANCK 服务器，uname -r 的结果落在 5.10 系列。资料中的 Copy Fail 安全通告把这个内核组合列为受影响环境，对应的龙蜥修复公告是 ANSA-2026:0565。此时无需先搜索 EXP，最短且可靠的排查路径是：查目标发行版公告、核对已安装内核包是否达到 fixed version、按公告升级、安排重启，最后重新检查运行中的内核。

uname -r
cat /etc/os-release

核心结论是：uname -r 只能帮助缩小候选范围，不能直接证明系统存在漏洞，也不能证明漏洞已经修复。发行版可能向同一个内核 release 回移安全补丁，所以最终必须落到“目标厂商公告中的修复包”和“机器实际运行的版本”这两个证据上。这也是由 Hacker News 的 Local privilege escalation vulnerabilities in Linux 相关入口引出的排查重点：不是复述漏洞或演示提权，而是把版本线索转换为可复核的补丁状态。

uname -r 只能缩小范围，先把发行版认准

uname -r 返回当前内核的 release 字符串，uname -v 返回内核构建版本，uname -m 返回机器架构。uname -m 主要用于确认架构，而且 64 位硬件也可能运行 32 位内核，不能仅凭机器位数判断系统实际加载了哪种内核。

uname -r
uname -v
uname -m
cat /etc/os-release
cat /etc/redhat-release 2>/dev/null

排查记录至少要同时保留内核 release、构建版本、架构、产品名称、产品线和服务包信息。/etc/os-release 适合确认发行版名称和版本字段，但不能代替公告中的产品线判断。例如，同样是 5.10 内核，Anolis OS 8、Anolis OS 23 以及其他发行版需要分别查询自己的公告，不能把上游 stable 分支的修复直接等同于下游系统已经打上补丁。

Debian、Ubuntu 上还可以查看已安装的镜像和头文件包：

# 仅 Debian / Ubuntu
dpkg-query -W 'linux-image-*' 'linux-headers-*' 2>/dev/null

linux-headers-* 是内核头文件包，供编译内核模块等场景使用。它存在，只能证明对应头文件已经安装，不能证明当前运行内核包含某项安全修复。

普通无独立内核的容器通常共享宿主机内核，因此容器里的 uname -r 可能反映宿主机，而容器内的 /etc/os-release 又可能来自镜像本身。此时应在宿主机重新查询发行版、内核包和修复公告；虚拟机有独立内核，按虚拟机自己的系统排查。

按目标发行版公告找 fixed version，别拿上游号对号入座

排查时可以把证据分成三层。三者不能互相替代，证据强度由弱到强：

因此，查到 CVE 的版本范围后，下一步不是立即升级，而是进入目标发行版的官方公告。Ubuntu 和 Debian 分别看 Ubuntu Security Notices 与 Debian Security Tracker；RHEL 看 Red Hat Errata；SUSE 与 openSUSE 看 SUSE CVE 页面和 openSUSE Security。CentOS Stream、AlmaLinux、Anolis 等 RHEL 衍生系统应优先查各自公告，不能直接套用 RHEL 的包版本。麒麟、统信也应使用对应产品公告和升级渠道。

Copy Fail 的版本映射就体现了这种差异。资料分别以 CNVD-2026-19044 和 CVE-2026-31431 报道该问题；上游提供了 stable 分支修复提交，龙蜥则把 Anolis OS 7、8、23 分别映射到 ANSA-2026:0566、ANSA-2026:0565、ANSA-2026:0564。 上游有提交，不等于所有下游发行版都已经发布并安装对应包。

Dirty Frag、Fragnesia 的排查记录也应保存漏洞名称、CNVD 标识、受影响组件、补丁提交、fixed package、erratum 编号和重启要求。现有汇总通告列出了 Dirty Frag 的 CNVD-2026-21358、CNVD-2026-21360，以及 Fragnesia 的 CNVD-2026-21361，并给出了部分上游 stable 提交；这些信息仍然要回到每个目标厂商的 erratum，才能获得该产品的实际修复包。 PoC 或 EXP 页面可以帮助发现线索，但不能证明某个发行版已经修复。

确认公告后，再查看本机包状态：

# Debian / Ubuntu：查看当前内核镜像包的已安装版本与候选版本
apt-cache policy linux-image-$(uname -r)
dpkg-query -W 'linux-image-*' 2>/dev/null

# RHEL 系、Anolis、SUSE/openSUSE：列出已安装的内核相关包
rpm -qa 'kernel*'

apt-cache policy 中的 Candidate 取决于机器实际配置的软件源；如果 Candidate 没有达到公告列出的 fixed version，还要检查安全更新源是否启用、公告是否要求安装另一个 ABI 包。不要仅凭候选版本较低就断言系统必然存在可利用漏洞，也不要在未核对公告前执行全量升级。

即使版本命中，也要记录利用前提。例如 CVE-2026-64600 影响 XFS reflink 路径，目标环境是否实际使用相关文件系统和工作流，决定了这条利用路径是否具备条件。

# 查看当前 XFS 挂载；具体业务是否使用 reflink 仍需结合环境确认
findmnt -t xfs

前提不成立只能说明当前暴露面较小，不能代替补丁安装。公告已经提供修复版本时，仍应按厂商要求升级。

更新后确认内核与用户态组件的修复状态

内核包安装成功不等于修复已经生效。安装操作通常只是把新内核写入磁盘并调整启动配置，正在运行的内核不会因此被热替换。要确认修复生效，需要同时满足：目标公告给出了对应修复包、修复包已经安装、机器已经启动该修复内核；公告涉及用户态组件时，还要单独核对对应软件包。

重启后可以再次记录运行态信息：

uname -r
uname -v
cat /proc/version

# Debian / Ubuntu：确认当前内核文件属于哪个已安装包
dpkg-query -S /boot/vmlinuz-$(uname -r) 2>/dev/null

# RHEL 系、Anolis、SUSE/openSUSE：确认当前内核文件属于哪个已安装包
rpm -qf /boot/vmlinuz-$(uname -r) 2>/dev/null

uname -v 可以辅助观察构建是否变化，但不能单独替代包版本和厂商公告。厂商也可能使用不同构建号回移同一项修复，因此最终仍应把运行内核映射回已安装包，再与 fixed package 对照。

新内核已经安装、uname -r 仍显示旧内核，通常意味着尚未重启或默认启动项没有切换。核对启动配置并安排重启后，再重复上述验证。在新内核成功启动、相关模块和服务验证正常之前，不要贸然删除旧内核。

本地提权问题不全在内核漏洞中。util-linux 的 mount target TOCTOU 问题被单独跟踪为 CVE-2026-53613，需要按照目标发行版公告核对 util-linux 软件包，而不是用“内核已更新”代替检查。

# 只读取当前 mount 所属组件版本；是否达到修复要求仍以官方公告为准
mount --version

Python 的 CVE-2022-42919 也有明确边界：资料指向 Linux 上的 Python 3.9、3.10 和 3.11.0rc2；只有在应用使用非默认的 forkserver 启动方式，并且允许不可信反序列化数据进入 forkserver 流程时，才需要重点排查。

python3 --version
ss -lx | grep '@listener'

后一个命令仅做只读检查，用于发现名称类似 listener-{forkserver_pid}-0 的抽象监听套接字。没有匹配结果不能单独证明系统不受影响，还要核对 Python 版本、应用启动方式和发行版补丁状态；出现匹配项也不等于已经确认命中该 CVE。

对于自编译内核、深度定制系统或已经 EOL 的发行版，通用升级命令往往无法提供可信结论。此时应把状态标记为“暂无法确认”，联系厂商确认补丁映射，或安排发行版迁移。整个判断过程不需要下载 EXP 尝试提权，sudo 策略和 SUID 文件审计也应作为独立的安全检查，不与内核补丁状态混在一起。