centos服务器系统内核漏洞修复实操

CentOS服务器内核漏洞修复不是“跑一条命令”就完事，很多运维在实操时卡在重启策略、内核版本选择和回滚预案上。先明确一个核心事实：CentOS 7和CentOS Stream 8/9的修复路径完全不同，CentOS 7在2024年6月30日已经EOL，官方源不再推送普通安全更新，而CentOS Stream还在滚动更新。如果你还在用CentOS 7，第一条要做的不是yum update，而是先确认你是否接入了Vault源或第三方ELTS支持，否则根本拉不到新内核包。

实操前先做三件事：记录当前内核版本、确认/boot分区剩余空间、检查是否有自定义驱动或第三方内核模块。很多人直接升级后重启失败，就是因为/boot空间不足导致initramfs生成不完整，或者装了ZFS、显卡驱动、网卡驱动等DKMS模块，新内核没有对应模块直接无法启动。执行uname -r看当前内核，df -h /boot看空间，ls /etc/dkms看是否有动态内核模块。如果/boot小于200MB，先清理旧内核再操作。

CentOS 7已经停止维护，官方mirror.centos.org不再提供7的更新包，但vault.centos.org还保留历史包。如果你只是想修复已知CVE，需要先切换到Vault源，或者直接迁移到RHEL的免费开发者订阅、AlmaLinux、Rocky Linux等兼容发行版。切换Vault源只能拿到旧的最终版本内核3.10.0-1160，如果漏洞是在EOL之后新发现的，Vault里根本没有修复包。所以对于生产环境，CentOS 7的正确修复策略是：要么购买ELTS商业支持，要么原地迁移到AlmaLinux/Rocky Linux，用它们的内核继续获得安全更新。

原地迁移操作不复杂，以AlmaLinux为例：先备份数据，然后下载almalinux-deploy脚本，执行bash almalinux-deploy.sh，脚本会自动替换CentOS的仓库配置并安装AlmaLinux的内核。迁移完成后重启，uname -r会变成AlmaLinux的4.18或5.14内核。这个过程会替换内核包，原有的应用和配置基本保留，但一定要先在测试机验证，尤其是涉及商业软件授权绑定的场景。

CentOS Stream 8和9还在维护周期内，内核漏洞修复直接用dnf更新。但要注意，Stream是滚动更新的，内核版本会持续升级，不能只盯着某个CVE的修复包，而是要保持定期更新。执行dnf check-update kernel查看可用内核版本，然后dnf update kernel只升级内核包，避免一次性更新所有包带来不可控变化。更新完成后，grubby --default-kernel确认新内核是否被设为默认启动项。

如果更新内核后需要立即重启生效，执行reboot。但生产环境通常不能随时重启，CentOS Stream没有像Ubuntu Livepatch那样的官方热补丁服务，所以要么接受重启窗口，要么用kpatch自己打热补丁。kpatch的使用方法是：安装kpatch和kpatch-build，下载对应CVE的补丁源码，编译成.ko模块，然后kpatch load加载。这种方式适合不能重启的关键服务器，但操作门槛较高，且不是所有漏洞都适合热补丁。

当官方源没有及时推送修复包，或者你需要修复一个特定CVE而其他更新不想动时，可以手动编译内核。先确认漏洞对应的内核补丁，从kernel.org或发行版的git仓库找到补丁文件。下载当前内核版本的源码包，解压后进入源码目录，执行patch -p1 < /path/to/cve-fix.patch应用补丁。然后复制当前系统的/boot/config-$(uname -r)作为.config，执行make olddefconfig，再make -j$(nproc)编译。

编译完成后安装模块和内核：make modules_install && make install。这会自动更新grub配置。手动编译的优点是精准可控，缺点是耗时且需要编译环境，生产服务器上通常不建议直接编译，而是在专门的构建机上编译出rpm包再分发。如果你要长期维护自编译内核，建议用rpmbuild把内核打包成rpm，这样后续升级和回滚都更方便。

内核升级或打补丁后，必须验证漏洞是否真的修复。方法是用漏洞检测脚本或工具，比如spectre-meltdown-checker检查CPU类漏洞，或者根据CVE描述编写简单的PoC验证。同时检查dmesg有没有新内核的报错，尤其是驱动加载失败、文件系统异常等信息。执行uname -r确认运行中的内核版本，lsmod看关键模块是否正常加载。

回滚预案必须在操作前就准备好。CentOS的grub默认保留多个内核，重启时在grub菜单选择旧内核即可回滚。如果系统已经无法启动，用安装介质进入rescue模式，chroot到系统目录，然后grub2-set-default指定旧内核，或者直接修改/etc/default/grub中的GRUB_DEFAULT参数。更稳妥的做法是操作前用dd或rsync备份/boot分区和/etc/grub*配置文件，这样即使grub损坏也能快速恢复。

单台服务器手动操作可以接受，但超过10台就应该考虑自动化。用Ansible写一个playbook，逻辑包括：检查当前内核版本、检查/boot空间、备份grub配置、执行dnf update kernel或yum update kernel、验证新内核文件存在、生成报告。对于CentOS 7迁移到AlmaLinux的场景，也可以写成Ansible任务，先在测试组执行，确认无问题后再推送到生产组。

长期维护的关键是建立内核版本基线。记录每台服务器的内核版本、已修复CVE列表、下次计划更新时间。用漏洞扫描工具定期扫描，发现新CVE后评估影响，如果CVSS评分高且可远程利用，立即安排修复；如果评分低且需要本地访问，可以合并到月度维护窗口。不要每次只修一个漏洞，而是按周期批量更新，减少重启次数和变更风险。

# 检查当前内核和/boot空间
uname -r
df -h /boot

# CentOS Stream更新内核
dnf check-update kernel
dnf update kernel -y
grubby --default-kernel

# 查看已安装的内核
rpm -qa | grep ^kernel

# 清理旧内核（保留当前和上一个版本）
package-cleanup --oldkernels --count=2

# 迁移CentOS 7到AlmaLinux
curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
bash almalinux-deploy.sh
reboot

内核漏洞修复的难点从来不是命令本身，而是变更管理。重启窗口、业务影响、回滚能力、验证手段，这些才是决定修复成败的因素。CentOS 7用户要尽快做出决策：迁移到哪个发行版、什么时候迁移、迁移后的内核维护策略是什么。CentOS Stream用户则要把内核更新纳入常规运维流程，而不是等漏洞爆发了才临时操作。内核安全是一个持续过程，不是一次性项目。