美国服务器内核补丁装了不等于修好：重启这一步别省

栏目里8月25日那篇（美国服务器收到高危漏洞预警后，48小时该做什么？）讲的是完整的应急流程：先确认影响面，快照留证再升级，止血，回头查痕迹。那套流程对大多数漏洞都适用，但有一类漏洞，会在其中一步上让人栽跟头，就是内核漏洞。栽的地方也很具体：补丁装了，机器没重启。

9月18日，美国CISA把两个Linux内核漏洞加进了已知被利用漏洞目录（KEV）：CVE-2025-39964和CVE-2026-53266，给联邦机构的修复期限是9月21日，前后只有三天。

其中CVE-2026-53266评分8.8，出在netfilter bridge的ebtables SNAT模块。它在改写ARP报文里的发送方硬件地址时，没有先确认要写的那段缓冲区可写，结果可能直接改到不相干的内核对象或用户态映射的内存，本地攻击者可以借此提权。CVE-2025-39964是内核加密接口AF_ALG的一个竞争条件，可能导致加密结果错乱或拒绝服务。

再往前一个月，8月27日，另一个影响IPv6子系统的内核提权漏洞CVE-2026-53362也进了KEV，当时CISA还要求联邦机构做入侵取证分级。一个多月里，两批内核提权漏洞先后进目录。

联邦期限已经过去一周了，补丁大多数人应该都装了。问题是，装了不等于在跑。

为什么内核补丁"装了还没打"

普通软件的补丁，装完重启对应服务就生效。Nginx升级完reload一下，OpenSSL升级完把用到它的进程重启一遍。

内核不一样。apt或dnf装上的是一个新的内核包，放在/boot下面，要等下次开机才会被加载；当前内存里跑着的，还是开机时那一颗旧内核。

常见的情况是：apt upgrade跑完，终端一片正常输出，人就走了。机器几个月甚至一年多没重启，/boot里躺着好几个越来越新的内核，一个都没用上。

确认起来很简单。先看当前跑的是哪一个：

uname -r

再跟已经装上的最新内核对一下：

• Debian / Ubuntu：dpkg -l 'linux-image*' | grep ^ii 列出已安装的内核；Ubuntu上如果存在 /var/run/reboot-required 文件，说明有更新在等重启。
• RHEL / Rocky / AlmaLinux：执行 dnf needs-restarting -r，提示需要重启，就说明新内核还没用上。

两边版本号对不上，这台机器对9月这两个漏洞来说，门还是开着的。

如果系统本身已经停止维护，比如Debian 11，那就不是重不重启的问题了，新内核根本等不来。这种情况香港栏目9月25日那篇（香港服务器系统停更自查）单独讲过，美国机器同样适用。

先分清，这颗内核是谁的

内核漏洞还有一点跟普通漏洞不同：一台物理机上可能跑着很多个"系统"，但内核可能只有一颗。

• 独立服务器：内核是你的，打补丁、重启都得自己来。
• 独服上自己装了PVE、KVM切虚拟机：宿主机的内核是你的，每台虚拟机的内核也要各自升级。宿主机那颗尤其要紧，它出事，上面所有虚拟机都跟着受影响。
• 独服上跑Docker、LXC：容器和宿主机共用同一颗内核。在容器里执行uname -r，看到的就是宿主机的版本，容器里也没法升级内核。
• 云服务器（KVM这类完整虚拟化）：你看到的内核是你自己的，要自己升级、自己重启；底下宿主机的内核归云厂商管。
• OpenVZ、LXC这类容器型VPS，以及虚拟主机：内核在服务商手里，你能做的是问清楚他们修了没有。

第三条对在美国服务器上跑容器的团队最值得多看一眼。对内核提权漏洞来说，容器不是隔离边界，任何一个容器里的服务被拿下，攻击者都有机会借内核漏洞跳到宿主机。不少团队容器镜像更新得很勤，宿主机内核却好几个月没动过。

本地提权，为什么也要急

CVE-2026-53266是本地提权，没法直接从公网打进来，有人会因此把它排到后面。

可本地提权的作用恰恰是"接力"。攻击者先通过一个Web漏洞、一个弱口令的SSH，或者一个忘了关的开发服务拿到普通权限，再用内核漏洞把自己抬到root。全球服务器新闻栏目9月17日那篇（Vite开发服务器遭全网扫描）写过，暴露在公网的开发服务器正在被大规模扫描，这种途径拿到的通常就是一个普通用户的立足点，后面缺的正好是一次提权。

所以排优先级可以这样：多人共用的机器、跑容器或虚拟化的宿主机、对外提供Web服务的机器，放在最前面；只跑单一内部服务、没有公网入口的机器，可以稍后。

独服重启前，先把退路想好

云服务器重启基本没什么风险，最差也能回滚快照。美国独立服务器不一样，新内核起不来的情况确实会碰到：RAID卡或网卡驱动跟新内核不兼容，自己编译过的DKMS模块没有重建，GRUB默认启动项被改乱。机器在洛杉矶机房，开不了机又没有远程控制台，就只能等机房的人帮你处理。

重启之前，可以先做这几件事：

• 确认旧内核还在，GRUB菜单里选得回去。不要急着清理旧内核包。
• 提前问服务商：这台机器有没有IPMI或远程KVM，出问题时机房能不能协助在启动菜单里选回旧内核，工单大概多久响应。这件事别等重启之后才问。
• 用了DKMS模块的（比如部分网卡驱动、ZFS），先在测试机上确认能跟新内核一起重建。
• 挑好时间。洛杉矶现在是夏令时，比北京晚15小时，当地凌晨1点就是北京时间下午4点，在国内上班时间就能做洛杉矶的凌晨维护窗口，出了问题人也在线。11月1日美国结束夏令时后，时差变成16小时，对应北京时间下午5点。

暂时重启不了，先争取时间

有些机器确实不能说停就停。可以考虑两条路，但都只是过渡。

一是内核热补丁。Ubuntu有Livepatch（属于Ubuntu Pro），RHEL系有kpatch，SUSE也有自己的内核热补丁，这次SUSE针对该漏洞的安全公告里就涉及SLE 15 SP7的热补丁包。但热补丁并不覆盖每一个CVE，用之前要查清楚你的发行版有没有为这个漏洞出热补丁。

二是收窄触发面。CVE-2026-53266落在ebtables的SNAT功能上，大多数只跑网站、数据库的美国服务器根本用不到ebtables。先用 lsmod | grep ebt 看看相关模块有没有加载；没在用的话，可以在/etc/modprobe.d/下加一条 install ebt_snat /bin/false 禁止它被加载，已加载且确认没在用的，用rmmod卸掉。另外，过去几年netfilter相关的本地提权，常见的利用路径是借助非特权用户命名空间拿到网络管理权限，所以限制非特权用户命名空间（如调整 user.max_user_namespaces）也是业内常用的临时手段。不过它会影响rootless容器、部分浏览器沙箱这类功能，动之前先确认业务里有没有在用。

这两条都是在争取时间。找窗口重启，仍然是唯一真正的修复。

写在最后

内核补丁这件事，难点不在技术，在习惯。大家都会升级，但很少有人在升级完之后看一眼uname -r。9月这两个漏洞的联邦期限已经过了，这周正好把手上的美国服务器过一遍：当前跑的是哪颗内核，该谁负责，重启前的退路备好了没有。

SellBGP的美国服务器部署在洛杉矶CoreSite LA2、600 West 7th Street数据中心，提供7×24小时工单支持。独服用户计划重启前，可以先提交工单说明时间窗口，提前确认出现启动异常时的协助方式；美国云服务器用户建议重启前先做一次快照。经常被扫描、暴露面较大的业务，也可以把源站放到美国高防服务器后面，先减少被人拿到立足点的机会。

两个常见疑问

升级完内核，一定要马上重启吗？

对9月这两个已被在野利用的漏洞来说，越快越好。但"马上"不等于"不做准备就重启"，尤其是独立服务器：先确认旧内核可回退、远程控制台可用，再挑窗口重启，比仓促重启后开不了机稳妥得多。

容器镜像天天更新，是不是就不用管内核了？

不是。镜像更新的是容器里的用户态软件，内核始终是宿主机那一颗。宿主机内核不升级，镜像更新得再勤，对内核漏洞都没有作用。