Debian 13 在最新的内核安全更新中披露了多起 CVSS 9.8 的高危漏洞,其中 CVE‑2026‑64530 与 net/sched 流量控制子系统的使用后释放(UAF)缺陷、以及 CVE‑2026‑64535 与 NVMe over TCP 数据摘要不匹配时的使用后释放风险,成为本次实战演练的核心目标。下面以合法的授权环境为前提,展示漏洞原理、复现步骤以及成功提权后的典型表现,并给出防御建议。

漏洞原理与影响范围
- CVE‑2026‑64530
位于 linux 内核的 net/sched 子系统。该子系统负责流量控制(如 TC、qdisc)。漏洞触发条件是当特定的调度器对象在释放后仍被后续代码访问,导致 UAF(Use‑After‑Free)错误。攻击者若能在该路径上注入受控数据,可在内核态执行任意代码,从而实现本地提权。
- CVE‑2026‑64535
属于 NVMe over TCP 实现的摘要校验路径。数据传输过程中若出现摘要不匹配,内核会错误地释放已分配的缓冲区,却仍继续使用该缓冲区,同样产生 UAF。该漏洞仅在系统启用了 NVMe over TCP 服务(如存储服务器)时可被利用。
两者均属于 本地权限提升(LPE) 类型,影响 Debian 13 默认内核(6.12 系列),在未打补丁的环境中,普通用户即可通过精心构造的触发条件获得 root 权限。
复现环境搭建与触发步骤
以下步骤仅适用于实验室或授权的渗透测试环境,切勿在生产系统上直接操作。
- 准备靶机
- 安装 Debian 13(未升级到 DSA‑6405‑1 的内核版本)。
- 确认内核版本满足
uname -r包含6.12系列且未包含修复补丁。 - 为避免误触其他服务,关闭不必要的网络功能,仅保留
net/sched(默认启用)和nvme-tcp(可选)模块。
- 编写触发模块
- 使用
insmod加载一个最小化的内核模块,该模块在init函数中创建一个自定义qdisc(或 NVMe over TCP 目标)并立即销毁,以触发释放路径。 - 通过
module_param暴露一个整数参数trigger,当其被设为非零时执行触发逻辑。 - 编译时使用与靶机相同的内核头文件 (
linux-headers-$(uname -r))。
- 触发 UAF
- 以普通用户身份加载模块:
sudo insmod lpe_trigger.ko trigger=1(若系统限制普通用户加载,先使用setcap赋予cap_sys_module能力)。 - 触发后,内核会在释放调度器对象后继续访问,导致内核态执行路径被劫持。
- 利用占位符实现提权
- 通过
prctl(PR_SET_SECCOMP, ...)或类似方式在用户空间注入一个指向commit_creds(prepare_kernel_cred(0))的函数指针。 - 当 UAF 被触发,内核会跳转到该函数,实现
root权限提升。 - 成功后,
id命令返回uid=0(root),并可打开交互式rootshell(/bin/sh)。
以上过程不涉及实际恶意 payload,仅演示了利用思路。实际 PoC 代码请参考公开的安全公告或受信任的研究者发布的示例。

提权效果示例
完成上述触发后,普通用户会在终端看到类似如下输出:
$ id
uid=1000(user) gid=1000(user) groups=1000(user)
$ sudo ./trigger.sh # 实际触发脚本
[+] Exploit succeeded, spawning root shell...
# id
uid=0(root) gid=0(root) groups=0(root)
# whoami
root此时攻击者已获得完整的系统控制权,可进一步读取敏感文件、修改系统配置或在网络上横向移动。值得注意的是,若系统启用了 SELinux、AppArmor 等强制访问控制,仍有可能被阻断,但多数默认配置的 Debian 环境并未强制限制内核模块行为。
防御与修复建议
- 及时更新内核
- Debian 官方已在 DSA‑6405‑1 中发布了针对上述 CVE 的补丁,升级到
6.12.100-1(或更高)即可彻底消除风险。 - 使用
apt-get update && apt-get upgrade,随后重启使新内核生效。
- 最小化功能暴露
- 若不使用 NVMe over TCP,建议在
/etc/modprobe.d/中将相关模块列入黑名单(blacklist nvme_tcp)。 - 对于容器或虚拟化环境,确保
net/sched相关的 qdisc 配置保持默认,避免自定义调度器导致意外触发。
- 限制内核模块加载
- 使用
cap_sys_module能力控制或通过module.sig_enforce=1强制签名模块,仅允许经过审计的模块加载。 - 对普通用户禁用
modprobe权限,防止未经授权的模块注入。
- 监控与审计
- 开启
auditd,监控init_module、delete_module等系统调用的异常频率。 - 配置内核日志级别,捕获异常的
BUG、WARN信息,有助于提前发现潜在利用尝试。
- 补丁回滚测试
- 在更新前,先在受控的测试环境中验证新内核的兼容性,确保业务不受影响后再在生产环境推广。

- it2021
- it2021.com
- linux
- shell
- 日志监控
- 渗透测试
- 访问控制





山东 烟台 1F
这类本地提权漏洞真让人心惊。
B1
@ 日光华 本地提权确实防不胜防,内核层出问题太致命
2F
我的服务器用了NVMe over TCP,得赶紧打补丁。
3F
有没有办法在不升级内核的情况下做防御?
B1
@ 月亮不睡我不睡 可以试试黑名单nvme_tcp模块,再限制模块加载权限
4F
能否提供一个现成的PoC,省得自己写模块。
B1
@ 剑魄生 PoC不会公开,这类代码容易被滥用得谨慎对待
B1
@ 剑魄生 PoC公开风险太大,建议参考公开安全公告自己写
5F
prctl的使用看起来有点危险,慎重啊。
6F
复现门槛不低,普通用户没权限也玩不了。
B1
@ 橄榄绿意 所以普通用户想玩还得先搞定权限,门槛确实不低。
7F
开启了AppArmor的话,还会被利用吗?
8F
之前也遇到UAF,打完补丁后系统很稳。
9F
建议在生产环境关闭不必要的net_sched模块。
10F
这种高危漏洞对云服务器影响会有多大?
B1
@ 雪盲症候 云服务器风险更高,多租户环境下一旦被利用可能波及宿主
11F
看完提醒,马上检查下系统内核版本。
B1
@ 寒霜之瞳 记得确认一下内核版本号,6.12系列没修的话赶紧升
12F
及时打补丁比什么都强,别等被入侵才后悔
13F
建议用unattended-upgrades自动更新安全补丁
14F
模块签名机制能有效阻止未授权模块加载
15F
auditd规则设好后,异常调用一眼就能发现
16F
默认配置太宽松了,得赶紧加固。
B1
@ DarknessEmbrace 确实,尤其是生产环境,能关掉的模块还是尽量关掉比较稳妥。
17F
其实多数VPS默认没开nvme_tcp,风险面有限
18F
内核不升级的话,至少禁用模块加载也行
19F
commit_creds那段要是能图解就更清楚了
20F
用普通用户加载模块触发,这个操作门槛高吗
21F
测试环境折腾一下还行,生产上不敢乱动
22F
云服务商应该已经热补丁了,裸机用户得自己盯着
23F
UAF漏洞这几年出得真频繁,内核复杂度上来了
24F
黑名单模块这招挺实用,直接断了风险面
B1
@ Pinstripe Penny 谢谢认可!黑名单省事,不过内核更新才是根除。
江苏 连云港 25F
默认配置不限制模块加载,这有点危险吧
26F
打完补丁又要重启,生产环境又得找窗口
黑龙江 哈尔滨 B1
@ 风里来 找窗口比打补丁还难😂生产环境只能这么熬