内核栈溢出防护必须在编译阶段启用config_stackprotector=y等配置，运行时sysctl、启动参数完全无效；需直接检查/boot/config-$(uname -r)确认config_stackprotector=y、config_vmap_stack=y、config_strict_kernel_rwx=y是否均为y，缺一不可。
内核栈溢出保护不是运行时能“打开”的开关
内核栈溢出防护必须在内核编译阶段启用，sysctl、启动参数（如 mitigations=on）或 /proc/sys/ 下的任何配置项对它完全无效。如果你 grep /boot/config-$(uname -r) 发现 CONFIG_STACKPROTECTOR 是 is not set 或 =m，那说明当前内核根本没有插入 canary 检查逻辑——连触发 panic 的机会都没有，只会静默跳转到非法地址。
确认当前内核是否真启用了栈保护
别信文档，只信配置文件：
-
grep CONFIG_STACKPROTECTOR /boot/config-$(uname -r)—— 必须看到CONFIG_STACKPROTECTOR=y；=m无意义，is not set就等于没开 -
grep CONFIG_VMAP_STACK /boot/config-$(uname -r)—— 应为y，否则栈溢出可能跨页覆写相邻内存 -
grep CONFIG_STRICT_KERNEL_RWX /boot/config-$(uname -r)—— 推荐为y，防止攻击者篡改__stack_chk_fail调用点
注意：zcat /proc/config.gz 只在内核启用 CONFIG_IKCONFIG 且打包进镜像时才可用；多数发行版默认不启用，所以优先查 /boot/config-*。
为什么你改了 sysctl -w kernel.kptr_restrict=2 却没用
因为栈保护依赖编译器行为：GCC 在函数 prologue 插入 mov %gs:0x28, %rax 读 canary，在 epilogue 插入 call __stack_chk_fail。这些指令只有内核启用 CONFIG_STACKPROTECTOR 并用支持该特性的 GCC 编译时才会生成。运行时无法“注入”这些指令——就像你不能在已出厂的汽车上临时加装防撞梁。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
常见误判现象：
- 看到
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted→ 说明 canary 已生效，是好事 - 什么都没报，但系统偶尔崩溃或返回地址错乱 → 很可能根本没开
CONFIG_STACKPROTECTOR -
CONFIG_DEBUG_STACKOVERFLOW=y被误当成防护手段 → 它只是在栈底插 canary 并轮询检测，开销大，仅用于调试，生产环境应关掉
第三方预编译内核大概率不满足防护要求
Ubuntu 的 linux-image-generic、CentOS Stream 的 kernel-core 等通用包，通常只启用 CONFIG_STACKPROTECTOR_REGULAR（弱保护），且几乎从不开 CONFIG_VMAP_STACK。这意味着即使 CONFIG_STACKPROTECTOR=y，攻击者仍可能通过跨页覆写绕过检测。
真正起效的组合只有：
-
CONFIG_STACKPROTECTOR_STRONG=y（比_REGULAR更激进地覆盖更多函数） -
CONFIG_VMAP_STACK=y（x86_64 上还需CONFIG_RELOCATABLE=y） -
CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y（避免未初始化栈变量泄露内核地址）
闭源驱动（尤其是老版本 NVIDIA 模块）可能与 VMAP_STACK 冲突，上线前必须在真实硬件上实测——不是所有“能 boot”就代表“能稳定运行”。
