Linux不存在真正意义上的漏洞自动修补，尤其是内核级高危CVE，必须人工确认、部署和验证；所谓“自动”仅限于自动发现与下载补丁包，而非自动安装、重启或修改关键配置。
Linux 中不存在真正意义上的“漏洞自动修补”——尤其是内核级或高危 CVE，必须人工确认、部署和验证。所谓“自动”，仅限于自动发现、下载补丁包，而非自动安装、重启或修改关键配置。
unattended-upgrades 只能自动下载，不能自动装内核
Debian/Ubuntu 系统启用 unattended-upgrades 后，默认会下载安全更新，但内核包（如 linux-image-6.1.0-21-amd64）不会被自动安装，除非你显式开启危险选项：
-
Unattended-Upgrade::Install-On-Shutdown "true"—— 重启前强制安装所有待升级包，含内核，极易导致启动失败 -
Unattended-Upgrade::Automatic-Reboot "true"—— 自动重启，无业务停机窗口控制
正确做法是保持这两项为 "false"，再配合定时检查：
apt list --upgradable 2>/dev/null | grep linux-image
输出非空即告警，触发人工介入。否则，系统可能长期挂着未安装的内核补丁，CVE 实际未修复。
dnf-automatic 在 RHEL 系统中默认不装 kernel 包
RHEL/CentOS 8+、Rocky/AlmaLinux 默认配置下，dnf-automatic 即使启用了 download_updates = yes，也不会安装 kernel 或 kernel-core 包——这是设计行为，不是 bug。
原因在于：dnf-automatic 的安全更新策略默认只作用于 security 类别，而内核包通常归类为 baseos 或 appstream，除非你手动在 /etc/dnf/automatic.conf 中添加：
upgrade_type = security random_sleep = 300 emit_via = stdio download_updates = yes apply_updates = no # 必须显式指定内核包名模式 update_cmd = security update_command = /usr/bin/dnf update --advisory=RHSA-2024:XXXX
但即便如此，仍需人工运行 dnf install kernel-core-5.14.0-284.30.1.el9_2 并调用 grubby --set-default，否则新内核永远不会生效。
内核补丁 ≠ 漏洞修复，必须验证缓解机制是否启用
某些 CVE（如 CVE-2024-1086、CVE-2022-0847）虽有内核更新，但修复依赖运行时开关。例如：
-
Dirty Pipe需确认/proc/sys/vm/unprivileged_userfaultfd是否设为0 -
Stack Clash依赖vm.mmap_min_addr值是否足够高（通常 ≥ 65536） -
x86 MMIO Stale Data要求spec_store_bypass_disable=on写入内核命令行
仅升级内核版本号（uname -r 显示新版）不代表漏洞已缓解。必须运行：
sysctl vm.unprivileged_userfaultfd cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
输出 not vulnerable 或 mitigation: usercopy 才算真正修复。
AI 工具（如 CodeBuddy）目前无法替代人工修补流程
当前 AI 工具在 Linux 漏洞修补中存在明确边界：
- 无法获取真实 CVE 补丁上下文（如 Kernel.org commit hash、RHEL errata 文档）
- 对多文件联动修改（如同时改
drivers/char/tty_io.c和include/linux/tty.h）易遗漏依赖 - 无法判断是否需重建
initramfs（dracut -f）、重生成 GRUB 配置（update-grub）或重载模块（modprobe -r nvidia && modprobe nvidia）
它可辅助阅读 patch diff，但不能替代 grubby、dracut、dmesg 这些运维动作。把 AI 当成补丁阅读器用可以，当成部署机器人用会出事。
最易被忽略的一点：旧内核不清理，新内核不设默认，GRUB 菜单没刷新——三者任一缺失，都意味着你“以为修了”，其实系统还在跑带漏洞的老内核。
