DeafNews
// 3 ZERO-DAY · 6 CVE · 7 EXPLOIT IN THE LAST 24H→
Linux EXPLOIT

Linux Emulated Mainframe Driver Becomes a Path to Root Escalation

Published: Updated: By Samuel Segato 6 min read Linux
Share
WhatsApp Facebook X (Twitter) LinkedIn Reddit Telegram Email
A Linux kernel vulnerability allows local privilege escalation via an emulated SMC-D compatibility driver, with a public exploit demonstrated by XBOW. Affected versions include kernels prior to 6.12.97, 6.18.40, and 7.1.5. Red Hat declares all RHEL versions 6–10 "Not affected" because the vulnerable code is absent from their kernels.

On September 28, 2026, XBOW researchers published a working exploit for CVE-2026-72018, a Linux kernel vulnerability that exploits a mainframe compatibility driver to gain root privileges. The flaw resides in code that emulates the SMC-D protocol on x86 architecture—originally designed for IBM Z hardware—a concrete demonstration of how virtualization layers expand the attack surface beyond the original threat model’s boundaries.

Key Takeaways
  • CVE-2026-72018 is an out-of-bounds write in the kernel’s dibs_loopback driver, rated CVSS 7.8 (HIGH) by CVE.org and NVD
  • The XBOW exploit achieves root in 22 of 100 boots on Ubuntu 24.04 with kernel 7.1.0-rc6, mitigations disabled
  • The attack requires CAP_NET_ADMIN privileges to intercept and modify SMC-D handshake traffic via CLC
  • Red Hat declares all RHEL versions (6–10) "Not affected" because the vulnerable code is not present in their kernels

The Mechanism: When Emulation Removes Hardware Enforcement

The SMC-D (Shared Memory Communications – Direct) protocol was conceived for IBM Z and ISM (Internal Shared Memory) systems, where hardware natively enforces shared memory region boundaries. The dibs_loopback driver implements a virtual transport that replicates this behavior on standard Linux, making SMC-D available on x86 without specialized hardware.

The move_data() function copies data via memcpy() without verifying that offset + size falls within the DMB (Direct Memory Buffer) length. According to the CVE-2026-72018 record on CVE.org, "the loopback move_data() performs a memcpy into the registered DMB without checking if offset + size exceeds the DMB length." The record continues: "Unlike real ISM hardware, which natively enforces memory region boundaries, the software loopback lacks such protection."

The dmbe_idx and dmbe_size fields, controlled by the peer during the CLC (Connection Link Control) handshake, influence the offset calculation without any validation. The result is a constrained write primitive: 16 bytes of zeros at a partially controllable, 16 KB-aligned offset.

From Constrained Primitive to Root Shell: The XBOW Chain

XBOW turned this apparently weak primitive into privileged code execution. The exploit requires CAP_NET_ADMIN capabilities to configure SMC-D and intercept CLC traffic. Researchers used an nftables NFQUEUE rule to capture handshake packets, modify their fields, recalculate checksums, and reinject them into the stream.

The escalation technique relies on "heap grooming": positioning a kernel cred object immediately after the vulnerable buffer, then zeroing the target process’s euid, egid, suid, and sgid fields. This mechanism is documented in both the XBOW report and GBHackers’ technical analysis, which cites the test results.

According to GBHackers, citing XBOW data, "out of 100 separate boots, root privileges were obtained in 22 instances, with the first escalation occurring on the seventh boot." The CVE.org record confirms the fix adds "an explicit bounds check before the memcpy to reject such requests with -EINVAL."

"XBOW found and exploited CVE-2026-72018, a Linux kernel bug that human reviewers missed. The primitive looked too weak to matter, but it wasn’t."
— XBOW research blog

Affected and Unaffected Versions: The NVD Picture

According to NVD, the vulnerable code was introduced by commit f7a22071dbf316c982fb44308874bd7ad9ac2091. The first unaffected versions are 6.12.97 and later, 6.18.40 and later, and 7.1.5 and later. These numbers come from the NVD record, which GBHackers reports consistently.

Red Hat published a specific advisory with CWE-787 classification. The vendor explicitly states that all RHEL versions 6 through 10 are "Not affected," with the rationale "Vulnerable Code not Present." This exclusion is relevant for enterprise infrastructure administrators, but does not reduce severity for community or custom distributions that include the dibs_loopback driver.

Immediate Actions

  • Check whether the dibs_loopback driver is loaded on the system with lsmod | grep dibs and, if present, assess whether SMC-D is actually required for workloads
  • Upgrade to kernel versions 6.12.97+, 6.18.40+, or 7.1.5+ per your maintenance branch, verifying the changelog explicitly includes the bounds check in move_data()
  • Review capability profiles assigned to users and containers holding CAP_NET_ADMIN, minimizing those who genuinely require the privilege to operate SMC-D
  • Note that the XBOW exploit was tested with mitigations disabled: the step to an environment with active mitigations is not a guaranteed barrier, but it significantly alters the risk profile compared to the published lab data

The Compatibility Paradox: Hardware Absent, Threat Present

CVE-2026-72018 illustrates a systemic pattern in hardware abstraction layers. Code originally protected by physical constraints—here, memory boundaries enforced by IBM silicon—loses those guarantees when emulated in software. XBOW’s phrasing is precise: "Kernel code that was ‘practically unreachable’ becomes an ordinary attack surface the moment someone uses a virtual transport for it."

The discovery raises questions about security reviews applied to compatibility drivers. If SMC-D code was examined for threats in mainframe environments, the analysis did not anticipate a scenario where a local actor with network administration privileges manipulates virtual peer parameters. The original threat model assumed trusted hardware; virtualization removed that premise without updating boundary checks.

For security teams, the lesson is not SMC-D-specific. Every driver that replicates hardware behavior in software—especially those tied to memory management or transport protocols—deserves review under the assumption that the peer interface is potentially hostile. The 22% reliability with mitigations disabled is not an immediate risk for most production environments, but the public availability of the exploit changes the dynamics for multi-user systems where local access is already compromised.

Frequently Asked Questions

Why does Red Hat declare itself not vulnerable if the driver is in the Linux kernel?

Red Hat maintains a custom kernel for RHEL that does not include the dibs_loopback code. The vendor advisory specifies "Vulnerable Code not Present" for all supported versions. The vulnerability affects the upstream kernel and distributions that include it in full.

Does the 22% reliability make the exploit negligible in production?

The XBOW tests were conducted with kernel mitigations disabled, so the 22% figure is not representative of environments with standard protections active. However, lab reliability measures the correctness of the exploit chain, not its reproducibility under hardening. Publication of the code increases risk for systems where an attacker can repeat execution.

What is the relationship between this vulnerability and the other Linux LPEs cited by TheHackerNews?

TheHackerNews published an article contextualizing CVE-2026-72018 among four kernel vulnerabilities with public exploits. However, the other three (DirtyAH6, TUNderflow, PPPoEject) are the work of a different researcher, Asim Manizada, and share neither code nor mechanism with the XBOW flaw. The dossier documents no infrastructural overlap between these exploits.

Sources

Information verified against cited sources and current as of publication.

Sources

Sources and references
  1. gbhackers.com
  2. xbow.com
  3. access.redhat.com
  4. thehackernews.com
  5. cve.org
  6. nvd.nist.gov
  7. security.access.redhat.com