能打热补丁的前提是内核启用config_livepatch=y（或config_kpatch=y）且config_ftrace、config_function_tracer、config_kallsyms均为=y；否则即使安装kpatch工具也无效。
能打热补丁的前提不是装了 kpatch，而是你的内核必须启用 CONFIG_LIVEPATCH=y（或 CONFIG_KPATCH=y），且依赖项 CONFIG_FTRACE、CONFIG_FUNCTION_TRACER、CONFIG_KALLSYMS 全部为 y。否则所有后续操作都会静默失败或报 Operation not supported。
确认内核是否真正支持 Livepatch
很多人卡在这一步却以为是工具问题。运行以下命令检查真实配置：
zcat /proc/config.gz 2>/dev/null | grep -E '^(CONFIG_LIVEPATCH|CONFIG_KPATCH|CONFIG_FTRACE|CONFIG_FUNCTION_TRACER|CONFIG_KALLSYMS)' || grep -E '^(CONFIG_LIVEPATCH|CONFIG_KPATCH|CONFIG_FTRACE|CONFIG_FUNCTION_TRACER|CONFIG_KALLSYMS)' /boot/config-$(uname -r)
预期输出中每项都应为 =y。若出现 =m，需手动 modprobe livepatch（部分发行版禁用该模块）；若为空或 =n，说明内核不支持——此时装 kpatch-build 也编译不出可用模块。
- RHEL/CentOS 用户可快速验证：
uname -r输出含kernel-livepatch字样才可信 - Ubuntu 用户请优先用
canonical-livepatch status，它不依赖本地构建，但只覆盖 Canonical 官方 CVE - 自编译内核或旧版 Debian（如 12/11）大概率不满足条件，别硬试
使用 kpatch-build 构建补丁模块的硬约束
kpatch-build 不是“源码 diff 就能出模块”，它对 ABI 兼容性极其敏感。常见失败场景包括：
- 目标内核版本必须与
kernel-devel和kernel-debuginfo包严格匹配（连4.18.0-305.3.1.el8_4这种小版本号都不能错） - 补丁不能修改
__init函数、schedule()、sys_read()、sys_poll()等禁止热替换的函数 - 不能修改静态分配的全局变量，也不能 patch vdso 中的函数
- 若系统已加载
kprobes或启用了perf采样，kpatch-build可能因符号冲突失败
构建命令示例（假设你已准备好 vuln.patch 和对应内核源码）：
kpatch-build -s /usr/src/kernels/$(uname -r) -v /lib/modules/$(uname -r)/build/vmlinux vuln.patch
成功后生成 kpatch-vuln.ko，但注意：该模块仅对当前运行内核有效，换内核版本即失效。
加载补丁时的权限与生命周期陷阱
即使模块编译成功，insmod kpatch-vuln.ko 仍可能失败。关键点：
- 必须用
root权限，且 SELinux 处于permissive或disabled模式（enforcing下常拦截 ftrace 写入） - 补丁加载后不会持久化：重启后自动丢失，需通过 systemd service 或
/etc/rc.local重新加载（但要注意顺序——必须在kpatch内核模块就绪后） - 卸载前务必确认无进程卡在被 patch 的函数栈中，否则
kpatch unload会 hang 住；建议先用kpatch list查看状态 - 多个补丁存在依赖关系时，加载顺序错误会导致
Invalid argument错误
推荐用官方管理工具替代裸 insmod：
- RHEL/CentOS：
kpatch load kpatch-vuln.ko（自动处理依赖和回滚） - Alibaba Cloud Linux：
livepatch-mgr load /path/to/kpatch-vuln.ko - 浪潮 InLinux：
syscare install -p kpatch-vuln.ko
最易被忽略的一点：热补丁生效≠函数立即切换。Livepatch 采用渐进式迁移，正在执行旧函数的进程会继续跑完，新 fork 的进程才用新逻辑。这意味着漏洞修复存在时间窗口——尤其对长期驻留的守护进程，可能需要手动 kill -USR2 触发重载（若其支持），或等待自然进程更替。
