CVE-2026-31431修复实践：Anolis、RedHat、Ubuntu处置建议

导语

最近Linux内核本地提权漏洞CVE-2026-31431受到较多关注。这个漏洞也被业内称为Copy Fail，问题出在内核AF_ALG/AEAD相关处理路径上。对于一台只允许可信管理员登录的单用户主机，它的现实风险未必最高；但在多用户服务器、容器宿主机、CI/CD Runner、共享测试机这类环境里，风险就完全不一样了，因为低权限用户一旦能够在本地执行代码，就有机会继续向root提权。

先来看下官方的响应速度，几家主流发行版对CVE-2026-31431的处理都比较快：

• 按照Ubuntu官方披露口径，漏洞于2026年4月29日公开；Ubuntu在4月30日即发布官方缓解说明和kmod缓解；
• Red Hat也在4月30日发布官方漏洞公告和临时缓解建议，基本都属于1天内响应；
• Anolis OS则在2026年5月2日发布ANSA-2026:0564、ANSA-2026:0565、ANSA-2026:0566三份官方修复公告，约为披露后2至3天完成官方修复发布。

从处置思路上看，这类内核漏洞没有太多花哨空间，核心就三件事：先看发行版官方公告，再上正式修复；一时不能升级，就用启动参数做临时缓解；如果确认相关能力是模块方式加载，再补一层模块黑名单。 真正的修复标准也很明确，不是“已经执行过update”，而是“系统已经重启并运行在官方修复后的内核版本上”。

本文把AnolisOS、RHEL和Ubuntu三类系统放在一起梳理，方便运维团队直接落地。

 

注意：阿里云、清华等非官方镜像站通常会同步上游仓库的软件包，但同步速度和同步完整性并不完全等同于官方源。实际排查中，经常出现“修复包已经同步，但安全公告元数据尚未同步”或“镜像站已提供更新，但本机启用的仓库路径不完整”的情况。因此，使用第三方镜像源时，不能只看是否执行了yum update或dnf update，还应同时核对可用内核版本、CVE公告元数据以及当前启用仓库配置，确认修复包确实已经进入本机可见仓库。”

先看几个官方入口

如果你在做排查，建议先从发行版官方页面确认自己所在版本是否受影响，以及修复包是否已经进入仓库。

• Red Hat安全公告：https://access.redhat.com/security/vulnerabilities/RHSB-2026-002
• Red Hat CVE页面：https://access.redhat.com/security/cve/CVE-2026-31431
• Ubuntu CVE页面：https://ubuntu.com/security/CVE-2026-31431
• Ubuntu官方说明：https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available
• NVD CVE页面：https://nvd.nist.gov/vuln/detail/CVE-2026-31431

Anolis OS：先看ANSA公告，再升级内核

龙蜥这次给出的修复范围比较清楚，AnolisOS7、8、23都已经有对应安全公告：

系统版本	内核分支	官方公告
Anolis OS 7	ANCK 4.19	ANSA-2026:0566
Anolis OS 8	ANCK 5.10	ANSA-2026:0565
Anolis OS 23	ANCK 6.6	ANSA-2026:0564

如果是AnolisOS7或8，直接走yum 更新内核即可：

sudo yum clean all
sudo yum makecache
sudo yum update kernel
sudo reboot

如果是AnolisOS23，则使用dnf：

sudo dnf clean all
sudo dnf makecache
sudo dnf update kernel
sudo reboot

很多时候，真正的问题不是“怎么升级”，而是“仓库里到底有没有同步到修复版”。这时可以直接查安全公告和可用内核版本：

yum updateinfo info --cve CVE-2026-31431
yum --showduplicates list kernel

或者：

dnf updateinfo info --cve CVE-2026-31431
dnf --showduplicates list kernel

如果输出里已经能看到ANSA-2026:0564、ANSA-2026:0565、ANSA-2026:0566，说明当前启用的源已经同步了这次修复。接下来要看的不是“包装没装”，而是“运行内核切没切过去”：

rpm -q kernel
uname -r
needs-restarting -r

这里rpm -q kernel表示修复内核是否已经安装，uname -r表示当前实际运行的是哪个内核。很多环境里update之后没有立即重启，看起来补丁已经打了，实际业务还跑在旧内核上，这种情况并不算真正修复完成。

RedHat：官方缓解最完整，RHEL 8/9/10需要重点关注

RedHat官方将CVE-2026-31431定级为Important。根据官方公开信息，RHEL8、RHEL9、RHEL10需要重点关注，RHEL6、RHEL7不受影响。

官方资料入口如下：

• Red Hat安全公告RHSB-2026-002：https://access.redhat.com/security/vulnerabilities/RHSB-2026-002
• Red Hat CVE页面：https://access.redhat.com/security/cve/CVE-2026-31431
• RHEL影响范围说明：https://access.redhat.com/solutions/7141931

在修复动作上，RHEL的原则也很直接：先把修复内核装上，再安排重启窗口。

sudo dnf clean all
sudo dnf makecache
sudo dnf update kernel
sudo reboot

RHEL 8如果环境里仍主要使用yum，同样可以执行：

sudo yum clean all
sudo yum makecache
sudo yum update kernel
sudo reboot

根据官方公告，当时公开的修复版本示例如下：

系统版本	修复版本示例	官方公告
RHEL 8	kernel-4.18.0-553.123.1.el8_10	RHSA-2026:13577
RHEL 9	kernel-5.14.0-611.54.1.el9_7	RHSA-2026:13565
RHEL 10.0 EUS	kernel-6.12.0-55.71.1.el10_0	RHSA-2026:13887
RHEL 10.1	kernel-6.12.0-124.55.1.el10_1	RHSA-2026:13566

生产环境不要死记表里的版本号，真正有意义的是确认自己订阅的仓库里已经出现对应RHSA公告和修复内核：

dnf updateinfo info --cve CVE-2026-31431
dnf updateinfo list --cve CVE-2026-31431
dnf --showduplicates list kernel

如果是yum体系，则执行：

yum updateinfo info --cve CVE-2026-31431
yum updateinfo list --cve CVE-2026-31431
yum --showduplicates list kernel

部分企业环境会同时部署Red Hat kpatch。这种场景下，热补丁可以帮助你先压缩暴露窗口，但它不应替代正式的内核升级：

sudo dnf update kpatch-patch
sudo kpatch list

换句话说，kpatch可以帮你争取时间，但最终还是要在维护窗口里完成真正的kernel升级和重启。

Ubuntu：除了升级内核，还提供了kmod级别缓解

Ubuntu对这个漏洞的公开说明相对完整，除了CVE页面，还有单独的博客说明和USN公告：

• Ubuntu CVE页面：https://ubuntu.com/security/CVE-2026-31431
• Ubuntu官方说明：https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available
• Ubuntu USN-8226-1：https://ubuntu.com/security/notices/USN-8226-1

Ubuntu的正式修复路径依然是系统升级和内核升级：

sudo apt update
sudo apt upgrade
sudo reboot

不过Ubuntu这次还给了一个比较实用的思路，就是通过kmod侧做临时缓解，阻止algif_aead被继续加载。如果暂时不方便做完整升级，可以先把kmod升上去：

sudo apt update
sudo apt install --only-upgrade kmod

然后尝试卸载已加载模块：

sudo rmmod algif_aead 2>/dev/null || true

再检查它是否还在：

grep -qE '^algif_aead ' /proc/modules && echo "algif_aead loaded" || echo "algif_aead not loaded"

Ubuntu公布过的kmod缓解版本包括：

Ubuntu 版本	kmod 缓解版本
Ubuntu 22.04 LTS	29-1ubuntu1.1
Ubuntu 24.04 LTS	31+20240202-2ubuntu7.2
Ubuntu 25.10	34.2-2ubuntu1.1
Ubuntu 20.04 LTS	27-1ubuntu2.1
Ubuntu 18.04 ESM	24-1ubuntu3.5+esm1

可以这样确认当前主机上的状态：

dpkg -l kmod
uname -r
dpkg -l 'linux-image*' | grep '^ii'

Ubuntu这类方案的意义在于“先减风险”，但它和RHEL的kpatch一样，不能代替最终的正式修复。最终仍应落到升级后的内核版本和重启生效上。

为什么Boot参数比单纯黑名单更可靠

这次漏洞处置里，一个容易被忽略的点是：相关能力在某些内核版本中可能不是独立模块，而是built-in，也就是直接编进内核本体。 一旦是这种情况，单纯写一个blacklist algif_aead，并不能保证问题路径真的被禁用了。

这也是为什么RedHat官方明确给出了一组基于启动参数的临时缓解方式。优先推荐的是：

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

重启后用下面的命令确认参数已经进入内核启动项：

cat /proc/cmdline

如果输出中能看到：

initcall_blacklist=algif_aead_init

说明这条临时缓解已经生效。

如果需要更宽一点的限制范围，RedHat还给了两个备选：

sudo grubby --update-kernel=ALL --args="initcall_blacklist=crypto_authenc_esn_module_init"

或者：

sudo grubby --update-kernel=ALL --args="initcall_blacklist=af_alg_init"

这三种方式里，通常建议优先algif_aead_init，因为影响面相对更小；af_alg_init的覆盖范围更大，业务侧受到的波动也更可能明显一些。尤其在依赖内核加密接口、VPN、存储加密或者某些安全代理的环境里，最好先在测试环境验证。

等正式内核修复完成以后，记得把这个临时启动参数收回：

sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo reboot

模块黑名单该怎么用，边界又在哪里

模块黑名单不是没用，但它有很清楚的适用边界：前提是algif_aead的确以模块形式存在。 如果它本来就是内核内置，黑名单只能给人一种“已经处理了”的错觉。

判断方法并不复杂，先看内核配置：

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

结果通常可以这样理解：

结果	含义
CONFIG_CRYPTO_USER_API_AEAD=m	模块形式，可使用黑名单
CONFIG_CRYPTO_USER_API_AEAD=y	内置形式，黑名单不可靠

再看模块信息：

modinfo algif_aead

如果能看到.ko文件路径，通常说明它确实是模块。

确认可以用黑名单后，再去写配置：

echo "blacklist algif_aead" | sudo tee /etc/modprobe.d/blacklist-algif_aead.conf
echo "install algif_aead /bin/false" | sudo tee -a /etc/modprobe.d/blacklist-algif_aead.conf

如果当前已经加载过，还要把它卸掉：

sudo rmmod algif_aead

然后检查结果：

lsmod | grep algif_aead
modprobe -n -v algif_aead

理想情况下，modprobe -n -v algif_aead会显示：

install /bin/false

如果模块在initramfs阶段就被带起来了，还需要重建initramfs并重启。

RHEL/Anolis：

sudo dracut -f
sudo reboot

Ubuntu：

sudo update-initramfs -u
sudo reboot

所以，黑名单更适合当成一个附加防线，而不适合被当成“唯一修复方案”。

真正落地时，建议按这个顺序处理

如果要把这件事做得稳一点，建议顺序不要乱：

1. 先确认系统版本、当前内核版本，以及自己用的是官方源还是镜像源。
2. 再查发行版公告，确认CVE-2026-31431的修复包是否已经同步到本机启用的仓库。
3. 仓库里已经有修复版本的，优先直接升级kernel并安排重启。
4. 业务窗口暂时不允许升级的，先通过Boot参数降低风险。
5. 确认algif_aead是模块形式的，再叠加模块黑名单。
6. 正式修复完成后，清理临时缓解项，避免长期影响业务加密能力。

把几种手段放在一起看，优先级其实很清楚：

措施	推荐程度	是否需要重启	适用场景	主要局限
升级修复内核	最高	需要	所有生产环境	需要维护窗口
Boot参数缓解	高	需要	暂时不能升级、且怀疑built-in	可能影响加密相关业务
模块黑名单	中	通常需要	明确是模块加载场景	built-in场景下不可靠
kpatch	中高	通常不需要	已部署RHEL热补丁环境	不是最终修复
Ubuntu kmod缓解	中高	视情况	Ubuntu临时防护	仍需后续正式升级

最后验收，不要只看“装了没”，要看“跑的是不是新内核”

RHEL/Anolis建议至少确认这几项：

uname -r
rpm -q kernel
yum updateinfo info --cve CVE-2026-31431
dnf updateinfo info --cve CVE-2026-31431
cat /proc/cmdline
lsmod | grep algif_aead
needs-restarting -r

Ubuntu则重点看下面这些：

uname -r
dpkg -l 'linux-image*' | grep '^ii'
dpkg -l kmod
grep -qE '^algif_aead ' /proc/modules && echo "algif_aead loaded" || echo "algif_aead not loaded"

真正可以对外说“修复完成”的标准，至少应该满足下面几条：

• 官方仓库已经提供对应修复包。
• 本机已经安装修复版本。
• 系统已经重启并运行到修复后的内核。
• 临时缓解项处于可解释、可验证、可回退的状态。

结语

Copy Fail这类内核漏洞的处置，最容易出问题的地方不是命令不会敲，而是判断标准放得太松。执行过yum update、dnf update或apt upgrade，并不等于这台主机已经安全；真正重要的是，当前运行内核是否已经切换到官方修复版本。

如果只能给一个最实用的建议，那就是：优先升级官方修复内核；不能立即升级时，用Boot参数先压风险；确认是模块场景后，再补黑名单。 这样做虽然不复杂，但路径最稳，也最符合发行版官方的处置逻辑。