那个晚上，在AI辅助下我把家里那台老电脑修了 6 遍

共计 4128 个字符，预计需要花费 11 分钟才能阅读完成。

——从显卡黑屏到 3 个未修补的内核 LPE，再到一块快没电的 CMOS 电池：作为一个安全 PM，我为什么不放过任何 " 小问题 "

一、流亡的硬盘

那天下班前，公司那台陪了我两年的台式机——一块 H61 主板的低配机——突然不开机了。POST 没过，电源一闪就熄。

主板修不划算，我做了个决定：把硬盘和显卡拎回家，插到家里那台同样老的 X79 主板上接着用。

为什么这么折腾？因为那块硬盘是双系统：Windows 10 + Ubuntu 24.04。重装一次系统少说半天，把所有开发环境、配置、密钥重新搬一遍，得两天。只要硬盘没坏，主板坏了就只是换一台机器的事。

晚上 9 点，我把 GTX 660 从原机扒下来，连同硬盘一起塞进 X79 那台。开机，Windows 引导正常进了桌面，Ubuntu 也能起来——但 屏幕越看越不对劲：分辨率怪、字体糊。

那一刻我下意识做了一个 事后想起来错得离谱 的判断：会不会是 GTX 660 也跟着主板一起坏了？

家里抽屉还有一块从老笔记本拆下来的 GTX 950M（虽然是笔记本卡，但配上转接卡能在台式机上用）。换上吧，先不让显卡耽误事。

然后……灾难开始了。

二、错怪了一块好卡

GTX 950M 装上去，Ubuntu 桌面终于 " 看起来正常 "——分辨率对了、字也清楚了。我心想问题搞定，做我的事去。

直到我习惯性地 sudo reboot。

显示器 黑屏。
主机风扇 狂转。
硬盘灯 不亮。
键盘 NumLock 灯 按了没反应。

像一台被某个无形的手按住的机器——电是通的，但什么也没在跑。

等了 30 秒、1 分钟、3 分钟……还是这样。我只能 长按电源键强制关机。开机，进系统，一切正常。再 sudo reboot，又卡死。

当时的我，盯着那块嗡嗡作响的机箱，脑子里只有一个念头：这块 950M 是不是又坏了？

折腾了快 1 个小时之后，我意识到这事不对劲。我把 GTX 660 重新装回去。这次我决定 不再凭直觉做判断，而是好好把问题查清楚。

三、真相：是我自己装错了一整代驱动

把 660 装回去之后开机，跑 nvidia-smi，得到的回应是：

NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver.

我顺手查了下当前装的是哪个驱动：

$ dpkg -l | grep nvidia-driver
ii  nvidia-driver-535     535.288.01-0ubuntu0.24.04.2

535 系列。

然后我搜了一下：NVIDIA 在 495 版本之后，就完全放弃了 Kepler 架构（GTX 6 系 /7 系）的支持。也就是说——

535 这个驱动，在 GTX 660 上根本不会工作。

更荒诞的是：那块 " 被我冤枉 " 的 GTX 950M 是 Maxwell 架构 ，本来 535 是支持它的，但我有一种强烈的怀疑——之前公司那台机器上配的是 H61 + GTX 660，那套 Ubuntu 是当年配着 660 装的， 整套显示驱动是按 660 当年版本配的老驱动 。后来某次 apt 自动升级把驱动拉到了 535，但那时候机器还是 660， 所以显示其实早就半残了，只是表现得不那么明显。

塞进 X79 之后我看到的 " 分辨率怪、字体糊 "，根本不是硬件问题，是 nouveau 接管的回退显示 。我换上 950M 之后能正常显示，是因为 950M 的 Maxwell 架构是 535 驱动还支持的——但 sudo reboot 卡死那个现象，是另一个独立问题： 老 950M + 新内核 + 不完整驱动栈，关机阶段在卸载 nvidia 模块时死锁了，于是机器进了一个 " 半关机 " 状态。

这是给所有技术人的第一个钩子：

当一个症状出现的时候，最危险的不是没思路，而是凭直觉得出第一个结论，然后从此只为这个结论找证据。

我看到屏幕黑了，立刻就锁定 " 显卡坏了 "——但其实 显卡好得很，是我自己装了一个根本不该装的驱动。

打个比方：这就像 你给一台 iPhone 4 装了 iOS 18。系统看起来 " 装上去了 "，但开机之后要么黑屏要么没反应。你以为是手机坏了，其实是你逼一台 2010 年的硬件去跑 2024 年的代码。

修复方案很简单——但 简单不代表轻松。

四、给显卡找回它该穿的 " 码 "

GTX 660 是 Kepler 架构（2012 年的卡），NVIDIA 官方最后支持它的驱动分支是 470 系列。这就是它该穿的 " 码 "。

我做了这件事：

第一步：把当前的 535 系列彻底清干净，然后装 470。

sudo apt-get purge -y 'nvidia-*' 'libnvidia-*'
sudo apt-get autoremove -y
sudo apt-get install -y nvidia-driver-470
sudo reboot

重启完——nvidia-smi 依然失败。这是第二个坑。

排查发现：DKMS 包确实安装了，但编译模块这一步静默地失败了，根本没有 nvidia.ko 文件被生成到当前内核目录下。

DKMS 是什么？
一句话：它是显卡驱动和内核之间的 翻译官。

Linux 内核每升一次小版本（哪怕是个修 bug 的版本），它的 " 内部接口 " 都可能微调。显卡驱动要继续工作，就得 针对当前内核重新编译一遍——这件事就是 DKMS 自动做的。

如果哪天 DKMS 编译失败了（比如内核升得太新、驱动太老），它 不会大喊大叫——它只会把状态从 installed 变成 added，然后等着你某天发现。

我手动触发了一次编译：

sudo dkms install nvidia/470.256.02 -k $(uname -r) --force

这次它跑了出来，5 个 .ko 模块全部就位。nvidia-smi 终于亮起来：

NVIDIA GeForce GTX 660, Driver 470.256.02, 1991 MiB

第三步：保证下次开机能自动加载。

这一步必须做，否则关机后这套配置就丢了。我做了两件事：

# 把 nouveau 拉黑（防止它和 nvidia 抢 GPU）echo -e "blacklist nouveau\noptions nouveau modeset=0" \
  | sudo tee /etc/modprobe.d/blacklist-nouveau.conf

# 声明开机自动加载 nvidia 模块
echo -e "nvidia\nnvidia_modeset\nnvidia_uvm\nnvidia_drm" \
  | sudo tee /etc/modules-load.d/nvidia.conf

sudo update-initramfs -u
sudo reboot

重启之后再跑 nvidia-smi——一次成功。

整个过程花了大约 2 个小时。这 2 个小时里我至少强制关机了 5 次，怀疑过显卡、内存、主板、电源。但真正的问题，从头到尾就是一个：我让一个 2022 年的驱动去管一块 2012 年的显卡。

五、那就别再升级内核了

显卡的事搞定后，我又意识到一个隐患：Ubuntu 默认每个月都会推送新的内核 ABI 版本 。每次升级内核，DKMS 就要重新编译一次 nvidia 模块——而 470 驱动已经停止官方维护， 新内核出来又会越来越多和它不兼容的地方。

我突然不想再玩这个滚石上山的游戏了。我又不做内核开发，硬件也老了，何必每个月被 apt 推着走？

锁定内核版本，Linux 上用一行命令就能搞定：

sudo apt-mark hold linux-generic linux-image-generic linux-headers-generic

apt-mark hold 是什么？
想象 apt 是一个负责 " 管家 " 的角色，它每个月例行去仓库里给所有东西换新版本。hold 就相当于你 贴了张便条 在某几个箱子上写：" 这些不要动 "。其它箱子（浏览器、SSH 服务、桌面环境）该升还是升，只是内核不动。

想 " 撕便条 " 也只要一行：sudo apt-mark unhold。

到这一步如果停下，我也就是把一件 " 前期问题 " 做完了。但下一个钩子出现了——而且是真正属于我职业本能的。

六、安全 PM 的职业病发作了

我是做网络安全行业的产品经理。" 锁住内核 " 这个动作刚做完，脑子里立刻条件反射地冒出一句话：

最近几个月那几个挺火的 Linux LPE 漏洞，我这版内核打补丁了吗？

LPE = Local Privilege Escalation = 本地提权。白话翻译：你以普通用户登录到系统里，能找到办法变成 root。

这种漏洞看起来 " 我自己用的电脑无所谓 "——但在很多场景下它是 致命的最后一公里。比如：

• 一个 Web 漏洞让攻击者获得了 nginx 用户的 shell ——单独看是低危
• 但如果他在系统里能找到 LPE ——他能立刻拿到 root
• 1 + 1 = 拿下整台服务器

这就是为什么搞安全的人 对未打补丁的 LPE 漏洞如此敏感。

我查了下 2026 年 5 月公开的几个：

然后我对照了 Ubuntu 安全公告。结论让我手心微微一凉：

直到今天（2026-05-14），Ubuntu 24.04 还没有发布修复内核。
哪怕我现在解锁内核去升级到最新的 6.8.0-111，它也是 4 月 11 日打包的——比所有这三个漏洞披露日期都早。

升级也没用。

换句话说：全世界用 Ubuntu 24.04 的人，此刻都在裸奔。

打个比方：这就像 整个小区刚发现自己的门锁可以用回形针拧开 ，但是锁匠还没赶来。 等锁匠没有意义 ——你能做的事是 用别的方法堵住那扇门。

幸好这三个漏洞都不是无解的——Ubuntu 安全团队给出了 应用层缓解：

• Copy Fail：通过升级 kmod 包（不在我锁定的范围内）→ 自动 blacklist algif_aead 模块
• Dirty Frag (ESP)：手动 blacklist esp4、esp6 模块（我又不用 IPsec VPN，无影响）
• Dirty Frag (RxRPC)：手动 blacklist rxrpc 模块（AFS 文件系统，更没人用）

我写了个脚本一次搞定：

#!/usr/bin/env bash
# 缓解 2026-05 的三个 Linux 内核 LPE
set -e
sudo apt-get update
sudo apt-get install -y --only-upgrade kmod  # Copy Fail

cat <

$ sudo modprobe -n -v algif_aead
install /bin/false   # ← 拦截成功
$ sudo modprobe -n -v esp4
install /bin/true    # ← 拦截成功
$ sudo modprobe -n -v rxrpc
install /bin/true    # ← 拦截成功

# 1. RTC 时钟漂移：开机时硬件时间 vs 真实时间
timedatectl status

# 2. 历次开机时间是否合理（如果偶尔跳回 1970/2010，就是电池坏了）last reboot -n 10

# 3. 内核启动期 RTC 相关错误
sudo journalctl -b -k | grep -iE "rtc|cmos"