CVE-2026-68336 Fixes Linux Bonding Crash on IPv6 Disable

The newly published NVD record, sourced from kernel.org, tracks a null-pointer dereference in

. The upstream Linux commit changes three lines: it keeps the IPv6 Neighbor Solicitation send path compiled when IPv6 support exists in the kernel, but calls it only if

confirms that IPv6 is actually active at runtime.

That distinction is the heart of the failure. A kernel built with

retains IPv6-capable bonding code, yet a machine booted with

exits IPv6 initialization early. The

structure used by IPv6 routing is therefore never allocated. Before this fix, bonding could still attempt an IPv6 route lookup from its monitor worker and dereference that missing object.

The result is a kernel oops in

, with the reported trace running through

,

, and

. In practical terms, this is a host-stability bug triggered by an internally scheduled bonding health-check path, not a malformed-packet parsing flaw in the usual network-exposure sense.

The configuration combination that matters​

The CVE record describes a narrow but real combination: IPv6 is disabled globally at boot with

, while the bonding driver is configured in a way that continues to run ARP monitoring and its IPv6 Neighbor Solicitation validation path.

Linux bonding supports more than simple link-state polling. Its

option uses ARP probes to verify reachability through member interfaces, and

can configure IPv6 Neighbor Solicitation monitoring peers. Kernel documentation says ARP monitoring is disabled by default, requires an ARP interval greater than zero, and is mutually exclusive with the more common

carrier monitor.

The supplied crash trace specifically identifies the

workqueue and the active-backup monitor path. That means a system merely loading the bonding module is not enough to reproduce the problem. A bond using

alone, a bond without ARP monitoring, or a system that has not disabled IPv6 at boot should not enter the vulnerable sequence described by the record.

There is an operational wrinkle here. Administrators sometimes disable IPv6 globally to simplify a legacy network policy, while retaining IPv6-oriented bonding settings in a reusable NetworkManager profile, an initramfs configuration, a cloud image, or a provisioning template. A host may therefore appear to be IPv4-only while its bond configuration still contains IPv6 monitoring targets. The pre-fix code treated “IPv6 compiled into this kernel” as sufficient reason to send those probes; the fix correctly distinguishes that from “IPv6 initialized and usable on this boot.”

That is more than defensive polish. A redundant interface intended to improve availability could periodically crash the machine that depends on it.

The fix stops an impossible IPv6 operation​

The upstream patch, authored by Zhaolong Zhang and committed through Linux networking maintainer Jakub Kicinski, adds a runtime guard around

in

. Bonding continues to send normal ARP validation traffic, but it skips IPv6 Neighbor Solicitation probes if IPv6 is disabled.

The change is deliberately small:

• The IPv4 ARP-monitoring path remains unchanged.
• The IPv6 Neighbor Solicitation path remains available when IPv6 is enabled.
• The new runtime check prevents the route lookup that would access net->ipv6.devconf_all after boot-time IPv6 disablement.

The Linux commit identifies the original regression as the earlier change that added

to bonding. NVD maps the affected source line from Linux kernel 5.18 forward, rather than treating all historical bonding implementations as vulnerable. That version boundary is useful, but it should not be mistaken for an exact package-level patch matrix.

Linux distributions backport networking fixes aggressively, especially into enterprise kernels with version strings that lag far behind upstream. Conversely, a distribution may ship a kernel numerically newer than the affected baseline while not yet carrying a specific stable backport. Do not use uname -r alone as proof of remediation. Check the vendor kernel changelog, security tracker, or source RPM patch list for CVE-2026-68336 or the corresponding bonding fix.

Upstream fixed versions are already split by stable branch​

NVD’s initial affected-version data lists fixed upstream branch points at Linux 6.6.148, 6.12.101, 6.18.42, and 7.1.6, with the fix also present by 7.2-rc5. The CVE record links five kernel.org stable commits, indicating the correction was backported across multiple maintained streams rather than being left only in mainline.

That mapping exposes an important limitation in the initial advisory: it does not list fixed releases for every older long-term branch that might still be deployed commercially. In particular, the record’s public version range starts at 5.18, but its listed fixed branch releases begin at 6.6.148. That does not establish that every 5.x or 6.1-based vendor kernel is vulnerable or unpatched; it establishes only that the initial kernel.org record does not give administrators a complete downstream packaging answer.

NVD also has not assigned CVSS v3, CVSS v4, CWE, or a CPE product mapping as of August 11, 2026. That absence should prevent overstated severity claims. The record demonstrates a kernel null dereference and system crash under a specific configuration, but it does not presently document code execution, privilege escalation, data disclosure, or a network-reachable exploit chain.

For patch prioritization, this belongs below actively exploited remote-code-execution flaws but above routine housekeeping for infrastructure hosts that match the configuration. A bonded active-backup server can be a gateway, hypervisor, storage node, or cluster member; an avoidable kernel crash on such a node has consequences beyond the individual process that encountered it.

What Linux and Windows administrators should check​

Linux administrators should first establish whether the triggering conditions exist, then determine whether their vendor kernel incorporates the fix. The relevant checks are straightforward:

• Confirm whether the machine booted with ipv6.disable=1 by inspecting /proc/cmdline.
• Identify active bonds through /proc/net/bonding/ or the ip link and nmcli views used by the local distribution.
• Inspect each bond for an ARP polling interval and for configured IPv6 Neighbor Solicitation targets such as ns_ip6_target.
• Determine whether the bond uses ARP monitoring rather than miimon, because the documented crash path runs through the ARP monitor workqueue.
• Check the distribution’s kernel advisory or changelog for CVE-2026-68336 instead of relying solely on an upstream version number.

Until a patched kernel is deployed, the direct configuration workaround is to avoid the offending combination: remove stale IPv6 Neighbor Solicitation monitoring targets, use carrier monitoring where it satisfies the availability requirement, or avoid global boot-time IPv6 disablement if that policy is not actually required. Administrators should evaluate those changes carefully; altering bond monitoring can change failover behavior and may hide a genuine upstream connectivity failure.

For Windows-focused teams, the first task is scope control. Native Windows hosts are not affected by this Linux kernel CVE. The relevant exposure is in Linux systems under the team’s operational control: virtual appliances, Linux VMs on Hyper-V, Kubernetes worker nodes, router or firewall images, bare-metal backup servers, and potentially custom WSL 2 environments using a kernel and boot configuration that match the conditions.

The patch’s practical benefit is simple: a Linux host that has explicitly disabled IPv6 will no longer let bonding’s background monitor attempt an IPv6 route operation anyway. Administrators with bonded production links should treat that as a reliability fix, verify their distribution’s backport status, and remove contradictory IPv6 monitoring settings from templates before the next failover turns a configuration mismatch into a kernel crash.