AREX Feed Article
XBOW 称发现并武器化 Linux 内核漏洞 CVE-2026-72018：持 CAP_NET_ADMIN 的本地用户可提权至 root
9 月 29 日 19:36（UTC，北京时间 9 月 30 日凌晨 3:36），自主攻击安全公司 XBOW 在 ，称其发现并武器化了 Linux 内核漏洞 CVE-2026-72018：这是一处越界写（out-of-bounds write），能被持有 CAP_NET_ADMIN（Linux 的网络管理能力）的本地用户触发，并提供一个可用于本地提权（LPE）至 root 的原语。XBOW 称这项研究最终产出了可用的 LPE 利用，线程里附有一段演示，标注为「利用最终拿到 root shell（uid=0）」。
完整技术文发布于 9 月 28 日，题为《No Time to Pwn: CVE-2026-72018》，给出了。漏洞本身有第三方记录可查：公开的 显示，对应修复的补丁标题为「dibs: loopback: validate offset and size in move_data()」，CVSS 3.1 评分为 7.8（High）。利用链的机制、演示与成功率数据则均出自 XBOW 自己的博客与自测环境。
从 IBM 大型机代码，到普通 x86 上的回环
SMC（Shared Memory Communications，RFC 7609）是 IBM 设计的协议：两台服务器搬运大量数据时，传统 TCP/IP 栈要在逐包拷贝与头部处理上付出成本，SMC 让应用继续以普通 TCP socket 的方式工作，内核则把连接切到共享内存或 RDMA 路径上；对端不支持时退回普通 TCP。它有两个变体：SMC-R 通过支持 RDMA 的网卡读写远端内存；SMC-D 让同一主机上的两个虚拟机经内部共享内存（ISM）设备直接通信。
按 XBOW 的叙述，SMC-D 多年来实际上是 IBM Z 大型机上的代码，几乎没人审计，因为几乎没人能让它跑起来。变化来自近期的内核：SMC-D 被重构到名为 DIBS（Direct Internal Buffer Sharing）的抽象之上，并加入虚拟设备 dibs_loopback，使 SMC-D 无需专用硬件、通过回环即可运行。旧威胁模型（可信的大型机对端、由硬件中介的缓冲区）没有在这次移植中保留下来；XBOW 说，审计这次移植的人并不是从对抗视角思考「对端可控的 dmbe_idx」的那些人，边界检查因此没有被加上。
从握手字段一路到 memcpy：缺掉的边界检查
漏洞落在 SMC 的连接建立与发送路径上。SMC 连接通过一次简短的 TCP 握手建立（CLC：Proposal、Accept、Confirm），对端在报文中提供定位其共享缓冲区所需的四个字段：gid 标识 ISM 设备，token 指向 DMB（接收侧的直接内存缓冲区），dmbe_idx 是参与偏移计算的元素索引，dmbe_size 给出元素大小。四个字段都由对端选择，接收侧内核必须对照自己缓冲区的状态逐项检查。
连接建立时，smcd_conn_save_peer_info 用两个对端提供的值算出发送偏移：tx_off = bufsize × peer_rmbe_idx，其中 bufsize 由 dmbe_size 解压得到。发送路径上，smcd_cdc_msg_send 调用 smcd_tx_ism_write 时传入的 offset 参数为 0，tx_off 于是原样穿过 smc_ism_write 交给 DIBS 层；回环驱动的 move_data() 接着执行 memcpy(cpu_addr + offset, data, size)，既不检查 offset，也不检查 size 与缓冲区长度的关系。目标缓冲区是一个单独的 folio，长度 16,384 字节（16KB）。只要 dmbe_idx 足够大、把 offset 推过这个长度，32 字节的 CDC（Connection Data Control，连接数据控制）头就会落到相邻的内核堆内存上。XBOW 的总结是：从 CLC 字段到 memcpy，中间没有任何边界检查。
公开记录与这套机制吻合。CVE 记录的修复说明写道：回环 move_data() 在未检查 offset + size 是否超过 DMB 长度的情况下，对已注册的 DMB 执行 memcpy；与由硬件原生强制内存区域边界的真实 ISM 设备不同，软件回环没有这层防护，对端提供的越界偏移或过大的写入会导致越界写越过已分配的内核缓冲区；修复方式是在 memcpy 前加入显式边界检查，并以 -EINVAL 拒绝此类请求。评分向量是 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H，即攻击面为本地、所需权限为低权限。
XBOW 给出的时间线是：2026 年 6 月 19 日向维护者报告漏洞与补丁；7 月 7 日补丁获批并共享到 LKM（内核邮件列表）；8 月 17 日 CVE-2026-72018 被分配并公开；而 CVE 记录与 把公开发布日标为 8 月 15 日。
在单机上伪造对端：NFQUEUE 改写与 16 字节零写入
XBOW 写道，更早的威胁模型把 SMC 视为只有真正拥有 SMC 硬件的受害者才需要担心的攻击面，目标可能是虚拟机逃逸；博客作者对在那个环境里做虚拟机逃逸没什么兴趣，直说「我不关心这个框架。我要的是 LPE」。在单台机器上同时驱动客户端与服务端、走 DIBS 回环之后，「对端」变成了本地用户自己就能扮演的角色。
单机场景也带来权限前提。触发需要在两处用到 CAP_NET_ADMIN：一是注册让 SMC-D 启用的 UEID，二是用 nft 安装 NFQUEUE（把报文排队到用户态的机制）规则。XBOW 的假设因此是：一个不掌握 root、但持有 CAP_NET_ADMIN 的用户取得 root。它给出的理由是，容器运行时和网络守护进程都持有这一能力，权限提升研究也常以此为假设。
技术上，触发需要非零的 dmbe_idx，而回环 SMC-D 总是发送 dmbe_idx = 0。XBOW 起初把这个硬编码的零当作死路，后来转向改写传输中的回环 CLC 流量：用 nftables NFQUEUE 把回环输出报文排进用户态队列，用 libnetfilter_queue 挑出 CLC Accept 与 Confirm 报文，伪造字段、重算 IPv4 与 TCP 校验和，再重新注入。三个字段承担攻击：token 选择目标 DMB，dmbe_idx 放大 offset = bufsize × dmbe_idx，dmbe_size 决定 bufsize。
越界落下的是完整的 32 字节 CDC 头，但原语比这更窄：在发送方向的连接上，消费者游标与保留字段保持为零，可用的部分是从偏移 16 到 31 的 16 个零字节，它们会被写到攻击者选定的偏移上；该偏移是 16KB 的整数倍，可选范围达数 MB。XBOW 写道，限定为固定值的写入原语通常被视为弱原语，16 字节的零写入尤其难以利用；它因此把问题从「往哪里写什么」改写成「往哪里写零」。
把零写进 cred：100 次启动中成功 22 次
XBOW 把零写入的目标选为内核的 cred 结构。Linux 用 cred 保存进程的身份字段，权限检查读取的是 euid；当它读到零，内核就把该进程当作 root。把某个 uid=1000 进程的 cred 安排到写入路径上，这 16 个零字节就会覆盖 suid、sgid、euid 与 egid 四个身份字段；进程随后执行 setresuid(0, 0, 0)，就能得到干净的 root shell。因为零直接落在身份字段上，这条利用不需要额外的内存泄露，也从不依赖具体地址，只需让 cred.euid 处在写入路径上。
三个变量决定这次利用能否触发。其一，命中哪个缓冲区：SMC 会从池中复用缓冲区，无法预先知道写入的落点，XBOW 用 CLC token 把它钉住——用一条预热连接分配目标缓冲区并记录其 token，写入连接伪造同一个 token，使每次写入都落进同一缓冲区。其二，把 cred 放到缓冲区后面：先分配目标缓冲区，再大量派生 uid=1000 的子进程，让它们的 cred 在写入前进的方向上堆积；顺序反过来，cred 会落在缓冲区前面，向前写入就够不到。每个子进程调用 capset 来生成一份新的 cred，因为普通 fork() 只会共享父进程的 cred 并增加引用计数。其三，避免破坏利用自身：每次写入都需要新的 SMC 连接，写入有可能损坏把这些连接串起来的连接组（link group）连接树，令构建下一条连接时 smc_lgr_register_conn() 崩溃；在发现扫描过密会连锁破坏相邻结构、导致机器崩溃之后，XBOW 放宽了扫描步距，并让概念验证程序（PoC）在第一次成功后停止：某个被喷洒的子进程会轮询自己的 euid，读到零即完成提权，并通知父进程停止扫描。
由于利用依赖启动时确定的内存布局，XBOW 在 100 次独立启动中测量了成功率：22 次成功，第一次成功出现在第 7 次启动。测试环境是 Ubuntu 24.04（Linux 7.1.0-rc6/x86_64），并且关闭了全部内核缓解措施；XBOW 说，这是为了证明单一原语本身足以完成利用。
自主性失灵的三处，与 XBOW 的架构重构
XBOW 把这次研究同时呈现为一次自主性测试，并披露了它在哪些环节失灵。按博客的说法，XBOW 自主完成了威胁建模、代码审计、漏洞发现与验证，并承担了大部分利用开发；但有三个关键时刻需要人类判断来改变它的推理方向。
第一次，当研究从虚拟机逃逸转向本地提权时，XBOW 因为回环路径把 dmbe_idx 硬编码为零，一度认定 LPE 不可能。博客作者在检查它的推理时发现：XBOW 曾用一两句话考虑过拦截并改写外发报文，随后便放弃了这条路径，理由是嗅探、CAP_NET_ADMIN 以及额外的实现工作对一条不确定的路径来说太贵。博客里写道：「看到那个被放弃的想法时，我告诉它去试 MITM。」这条中间人改写路线随后走通：嗅探实现起来并不复杂，而 CAP_NET_ADMIN 本来就是 SMC-D 需要的。
第二次出现在利用开发阶段。XBOW 反复把单机模型误当成此前虚拟机模型中的「任意地址任意写」原语；「这是零写入」的口头纠正并不奏效，直到被要求亲手实验、确认原语只能写零之后，它才放弃错误假设。博客将此描述为：随着上下文累积，更新的推理埋掉了它已经确认过的事实。
第三次是防止绕路。接受零写入之后，XBOW 又执着于清零引用计数、把原语升级成更强的 UAF（use-after-free）；直到被要求就用零写入直接达成 LPE，它才停止寻找弯路，很快选定 cred 并完成利用。
XBOW 对这类失灵的总结是：LLM 不是人，但在漫长的研究过程中会发展出「出奇地像人」的偏见，偏爱熟悉、廉价的路径，过早放弃看起来昂贵的主意，有时把假设坚持得像信念；随着上下文增长，它甚至会丢掉自己早先发现的正确认识。博客认为这在某种程度上是强项的副作用：它极擅长阅读和推理代码，这自然把它拉向代码内部的答案，远离需要更昂贵推理或实现的路径。
XBOW 说，它真正想要的是让介入不再必要：问题出在架构上——一个 agent（智能体）独自承载整场长周期研究，还要在上下文里保存每个事实、假设与决定；它把工作重新分配给多个 agent，让每个 agent 维持合适的上下文。按 XBOW 的表述，结果是它现在能无需人类介入地自主发现并验证 Linux 内核漏洞、产出准确的补丁与干净的报告，并在需要时开发可靠的利用。
修复只是一个边界检查，可靠性被留给了读者
各家下游的评估与修复节奏各不相同：把该缺陷描述为「缺失的边界检查」，称其可能导致内存破坏、拒绝服务或任意代码执行，并把攻击复杂度评为 AC:H（High），比 cve.org 的 AC:L（Low）保守，因此自评基础分 7；Ubuntu 的跟踪页（9 月 22 日更新）上，26.04 LTS 的 linux 包仍标为「受影响，修复进行中」。
XBOW 提出的更大议题是：Linux 内核的攻击面正随着新的虚拟传输、DIBS 这类抽象以及各种「终于让某样东西可测试」的移植而扩大，每一处都是同一类 bug 的候选——对端可控字段流入偏移算术而没有边界检查，出现在原作者从未预期会在通用硬件上运行的代码路径里。它说，找出这类问题所需的测试是对抗性的、协议感知的、长周期的，必须自动化，才能跟得上新代码落地的速度。
XBOW 自己的结语说得更直接：晦涩的代码和弱原语都不意味着漏洞无关紧要，「如果攻击者哪怕只成功一次拿到 LPE，它就不再只是理论威胁」。它同时强调，这一成功率不是漏洞的固有上限：这是它刻意只用单一原语证明可利用性的结果；如果叠加它有意回避的内存泄露或 UAF 链，可靠性有明确的提升空间。这部分它没有做，留作对读者的公开挑战。