linux内核漏洞修复需人工主导：仅自动下载补丁，禁用自动安装与重启；人工确认默认内核、显式设新内核为默认并保留旧版；低峰期重启后验证版本、补丁及缓解机制。
Linux系统开启自动更新本身不难，但要安全修复内核漏洞，不能只依赖“自动升级”——内核更新必须重启、影响业务、存在回滚需求，盲目启用自动更新反而可能引发宕机。关键是在自动化和可控性之间找平衡：用自动机制发现并下载补丁，但把内核安装、默认启动项设置、重启时机等高风险操作留给人为确认。
一、分阶段配置自动更新：只自动下载，不自动安装内核
直接启用“自动安装所有更新”对生产系统是危险的。推荐采用“延迟执行”策略：
-
Debian/Ubuntu：编辑 /etc/apt/apt.conf.d/50unattended-upgrades，确保以下配置生效：
Unattended-Upgrade::Install-On-Shutdown "false";Unattended-Upgrade::Automatic-Reboot "false";
这样系统只自动下载并标记安全更新（含内核包），但不会安装，更不会重启。 -
RHEL/CentOS 8+/Rocky/Alma：使用
dnf-automatic，编辑 /etc/dnf/automatic.conf，将apply_updates = no（默认即为no），仅启用download_updates = yes和emit_via = stdio，配合 cron 每日检查更新状态。 - 所有系统都建议加一条监控命令，例如每天 6:00 运行：
apt list --upgradable 2>/dev/null | grep -E "(linux-image|kernel)" || echo "无待更新内核"（Debian系）
或dnf list updates kernel* 2>/dev/null | grep kernel（RHEL系）
输出结果可邮件或写入日志，提醒运维人工介入。
二、内核漏洞修复必须人工主导的三个动作
即使自动下载了新内核包，以下三步不可跳过，否则等于没修：
-
确认当前默认内核与待激活内核：
执行grubby --default-kernel记录当前默认；
安装新内核后（如apt install linux-image-$(uname -r | sed 's/-[a-z]//')-signed），用grubby --info=ALL | grep -E "(kernel|title)"查看全部内核条目，确认新版本已存在。 -
显式设为默认并保留旧内核：
grubby --set-default /boot/vmlinuz-<em>新版本号</em>（RHEL系）
或update-grub && grub2-set-default 0（需先grub2-mkconfig -o /boot/grub2/grub.cfg）；
同时确保/etc/default/grub中GRUB_DISABLE_RECOVERY="true"未启用，保留旧内核用于紧急回退。 -
计划低峰期重启并验证加载：
重启前检查服务依赖：systemctl list-dependencies --reverse multi-user.target；
重启后立即执行：dmesg | grep -i "linux version\|command line"，确认启动的是目标内核；
再运行uname -r交叉比对。
三、验证内核漏洞是否真正修复
版本号更新只是第一步，必须验证漏洞利用路径是否关闭：
- 查补丁是否落地：
Debian/Ubuntu：dpkg -l | grep linux-image | grep $(uname -r)确认安装时间与CVE公告发布时间匹配；
RHEL系：rpm -q --changelog kernel | head -20 | grep -i cve-2020-14386（以实际CVE编号替换）。 - 用工具复扫验证：
下载对应 CVE 的 PoC（如 CVE-2020-14386 的 afpacket 越界写 PoC），在测试环境运行验证是否无法触发；
或用lynis audit system --tests "kernel-hardening"检查 KASLR、SMAP、SMEP 等缓解机制是否启用。 - 检查容器逃逸防护（如适用）：
若运行 Docker/Kubernetes，确认unshare -r /bin/sh -c 'echo $$ > /proc/self/status'是否仍能读取宿主机 PID 域信息；
验证ls /proc/1/ns/中 user、pid、net 等命名空间是否隔离正常。
