Security firm XBOW has disclosed CVE-2026-72018, a high-severity (CVSS 7.8) out-of-bounds write in the Linux kernel’s DIBS loopback driver, the shared-memory transport used by SMC-D. XBOW says its autonomous agent found the bug and carried it all the way to a working local privilege escalation exploit, a class of flaw human researchers had largely overlooked in this code. No in-the-wild exploitation has been reported, but a public repository referencing the CVE already exists, so expect proof-of-concept code to circulate.

What’s broken

DIBS (Direct Internal Buffer Sharing) is the kernel abstraction layer that SMC-D builds on. Its loopback device lets two endpoints on the same host exchange data through registered Direct Memory Buffers (DMBs). The loopback move_data() routine performs a memcpy() into the destination DMB but never checks that offset + size stays within the DMB’s registered length.

Because the offset and size derive from peer-controlled CLC handshake data, an attacker can steer the write outside the allocated buffer. The primitive is narrow: a 16-byte write of zeros at a partly attacker-influenced kernel address. XBOW converted it into root by landing the zero-write on security-relevant fields of the kernel cred structure, including the effective UID, which flips the calling process to uid 0.

Affected versions

The bug was introduced in Linux 6.10 (commit f7a22071dbf3) and affects any kernel since then that ships the loopback driver without the fix. Upstream fixes:

  • 6.12.97
  • 6.18.40
  • 7.1.5
  • 7.2-rc3

The fix adds a validation step that rejects requests where offset + size exceeds the DMB length and returns -EINVAL instead of copying.

Exploitation requirements

Reported prerequisites are local code execution plus CAP_NET_ADMIN. That is not available to a plain unprivileged user on a default system, but it is routinely obtainable through unprivileged user namespaces on distributions that enable them, which is the usual route for turning “needs CAP_NET_ADMIN” into a practical LPE. Whether the SMC/DIBS code is reachable depends on the kernel build: check whether CONFIG_SMC and the DIBS loopback option are enabled or the modules are loadable.

Impact

This is a local escalation, not a remote vulnerability. The highest-risk environments are:

  • Multi-tenant Linux hosts and shared build runners where untrusted code runs as a local user
  • Container hosts and Kubernetes nodes where pods can create user namespaces or hold CAP_NET_ADMIN
  • CI/CD workers executing third-party code

Root on the host from a container context would also defeat namespace isolation, so treat unpatched, SMC-enabled container nodes as the priority.

Mitigation

  1. Patch. Move to 6.12.97, 6.18.40, 7.1.5 or newer, or pick up your distribution’s backport. Check vendor trackers such as Red Hat’s CVE page, since enterprise kernels backport fixes without changing the base version.
  2. Disable SMC if unused. Blacklist the smc and DIBS loopback modules (install smc /bin/true in modprobe config) on hosts that do not use SMC-D, and verify with lsmod.
  3. Restrict capabilities. Drop CAP_NET_ADMIN from workloads that do not need it and set kernel.unprivileged_userns_clone=0 (or the distro equivalent) where user namespaces are not required.
  4. Restrict loopback device access to privileged users, as upstream guidance suggests.

The broader point

The notable part is less the bug than how it was found. A one-line missing length check in a niche driver is the sort of defect that survives review for years, and an agent that can reason from a 16-byte constrained write to credential corruption compresses the time between disclosure and weaponization. Defenders should assume the gap between a kernel CVE appearing in linux-cve-announce and a working exploit will keep shrinking.

References