Analyzing the 19‑Year‑Old Linux Bonding Driver Type‑Confusion 0day (CVE‑2026‑43456)

1. Vulnerability Overview

The GMO Cybersecurity team disclosed a type‑confusion vulnerability (CVE‑2026‑43456) in the Linux kernel networking subsystem's net/bonding driver. Introduced in kernel 2.6.24 (commit 1284cd3a2b…) in 2007, it affects all kernels up to 6.12.77. An attacker with CAP_NET_ADMIN can gain root, leak KASLR, and achieve arbitrary code execution. The bug was rewarded over $80,000 by Google’s kernelCTF bounty.

2. Root‑Cause Analysis

2.1 Design Intent of the Bonding Driver

Bonding aggregates multiple physical NICs into a single logical interface, providing load‑balancing and fault‑tolerance. The logical interface is a bond device; the underlying NICs are slave devices.

The critical flaw resides in a single line of bond_setup_by_slave:

bond_dev->header_ops = slave_dev->header_ops;  // vulnerability trigger

header_ops

is a table of function pointers for handling packet headers. The bonding driver copies the slave’s header_ops to appear transparent, but some of those functions access the device’s private storage ( dev->priv). The bond device’s private area is a struct bonding, while a GRE tunnel’s private area is struct ip_tunnel. Their layouts differ, so the copy creates a type‑confusion.

2.2 Why It Remained Undetected for 19 Years

Exploiting the bug requires an elaborate chain of 329 GRE devices to adjust LL_RESERVED_SPACE to 0x3ec0, causing skb->data to overlap with skb_shared_info and trigger a controlled out‑of‑bounds write. Under normal configurations the bug does not cause observable crashes, and even tools like KASAN miss it. The issue was first triggered accidentally by the fuzzing tool syzkaller, which led to deeper reverse‑engineering.

3. Exploit Technique Chain

3.1 Stage 1 – KASLR Leak

The attacker uses an IPv6 GRE device. The recv_probe function pointer of struct bonding resides at offset 0x38. When the bond device is mis‑treated as an IPv6 GRE device, that offset maps to the GRE device’s laddr field, which can be controlled via incoming packets. Leaking this address reveals the kernel base, bypassing KASLR.

3.2 Stage 2 – Arbitrary Code Execution

Switching to a regular IPv4 GRE device, the exploit proceeds in two steps:

Step 1: SKBFL_ZEROCOPY_ENABLE flag manipulation – Due to the type confusion, the GRE hlen field is read as zero, causing skb_push() to miscalculate and make greh->flags overlap with skb_shared_info->flags. Writing the value 0x07ff sets the SKBFL_ZEROCOPY_ENABLE bit.

Step 2: Trigger callback execution – When the skb is marked zerocopy, skb_zcopy_clear() calls uarg->callback(). Using the leaked KASLR base, the attacker overwrites this callback with an address of commit_creds or prepare_kernel_cred, achieving root.

The full chain runs in under one second with a stability exceeding 99%.

4. Impact Assessment

All Linux servers with the bonding module enabled and users capable of CAP_NET_ADMIN.

Some cloud provider images that enable bonding by default.

Container hosts – if combined with container escape, the risk widens.

Although CAP_NET_ADMIN is a high‑privilege capability, it can be obtained by non‑root users via user namespaces or certain network‑namespace configurations, lowering the practical exploitation barrier in multi‑tenant environments.

5. Defense and Remediation Recommendations

5.1 Immediate Fix (Highest Priority)

Upgrade to a kernel version that includes the March 2026 security patch (commit 950803f7254). Verify the kernel version with:

# Check if the kernel is within the vulnerable range
uname -r
# Query distribution security advisories
# For RHEL/Fedora
dnf check-update --security 2>/dev/null
# For Debian/Ubuntu
apt-get -s upgrade 2>/dev/null | grep -i security

5.2 Temporary Mitigations

If a reboot is not possible, apply one of the following:

Disable the bonding module (recommended) :

# Prevent bonding from loading
echo "install bonding /bin/false" > /etc/modprobe.d/disable-bonding.conf
rmmod bonding 2>/dev/null

Most distributions do not enable bonding by default, so this has minimal impact on normal workloads.

Restrict propagation of CAP_NET_ADMIN :

# Disable unprivileged user namespaces (prevents gaining CAP_NET_ADMIN)
echo 0 > /proc/sys/kernel/unallowed_userns_clone
# or
sysctl -w kernel.unprivileged_userns_clone=0

Note: rootless Docker and similar tools will lose functionality.

Network‑namespace isolation : Enforce strict network‑namespace separation for untrusted workloads (e.g., containers, VPS) to block CAP_NET_ADMIN acquisition.

5.3 Detection and Monitoring

Deploy the following rules in a SOC platform:

SIEM rule : Alert on rapid creation of large numbers of GRE slave devices on a bonding interface.

HIDS rule : Detect abnormal loading of the bonding module. lsmod | grep bonding Network monitoring : Watch for unusual GRE tunnel traffic originating from containers or non‑privileged users.

6. Lessons for Vulnerability Discovery

The GMO team notes that a large language model assisted in parsing syzkaller crash logs, narrowing the suspect code region. However, they caution that “sleeping‑type” vulnerabilities that require extreme trigger conditions remain difficult for fully automated AI discovery, underscoring the continued need for manual deep analysis.

7. Conclusion

The CVE‑2026‑43456 disclosure demonstrates that a single innocuous assignment can persist unnoticed for nearly two decades, only surfacing when a highly crafted exploit is built. Security operations must maintain layered defenses, enforce the principle of least privilege for CAP_NET_ADMIN, and keep robust monitoring and response capabilities to handle both known and unknown kernel vulnerabilities.

References:

GMO Cybersecurity – “19‑Year‑Old Linux Kernel 0‑Day (CVE‑2026‑43456)” (July 2026)

@rqda_A – Twitter disclosure (July 3 2026)

Google Security Blog – kernelCTF bounty details