CVE-2026-68301 Linux HSR Fix Has Conflicting Version Ranges

The National Vulnerability Database published the record on August 10, 2026, after receiving it from kernel.org. Its description identifies a cleanup failure in

: when an HSR slave interface is removed while its HSR master remains active, VLAN IDs synchronized from the master can remain referenced on the departing slave. The resulting

and

allocations survive the destruction of that network device.

This is a resource-lifetime bug during network-interface teardown, not a report of packet corruption, privilege escalation, information disclosure, or remotely triggered code execution. NVD has assigned neither a CVSS score nor a CWE classification. That omission is appropriate at this stage: the published technical record explains the leak, but does not establish an attacker-controlled path to exploit it.

The leak occurs when HSR removes a slave device​

HSR is an industrial Ethernet redundancy protocol designed to keep traffic flowing when a link in a ring topology fails. Linux implements HSR and its related Parallel Redundancy Protocol support through the

driver, which creates a virtual master interface over two physical—or virtual—member interfaces. Kernel documentation describes the driver as a stackable network interface with two member ports, and the standard

tooling requires two slaves when creating an HSR device.

When an HSR master comes online, the kernel automatically adds VLAN ID 0 through

. That VLAN state is propagated to slave A and slave B. The expected reverse path matters just as much: when one of those slave devices is detached or destroyed, the HSR driver must withdraw the VLAN state it propagated.

Before this fix,

detached the slave without removing those synchronized VLAN IDs. The device could therefore retain a reference to VLAN 0, along with any other VLANs inherited through the HSR master. Once the network device itself was destroyed, the leftover references prevented the associated VLAN bookkeeping from being released.

The repair is small but targeted. Kernel.org’s patch invokes

before the HSR driver unlinks slave A or slave B. The change aligns HSR teardown with the VLAN-add and VLAN-remove paths already used by the driver, and with cleanup behavior found in Linux bonding and team drivers.

That symmetry is the important part. The defect was not that Linux could not delete VLAN information; it was that one destruction path failed to call the existing cleanup mechanism.

This is most relevant to long-lived industrial and edge systems​

A one-time HSR interface removal leaks a limited amount of kernel memory. The operational problem grows where interfaces are repeatedly created, destroyed, moved between network namespaces, or removed during service orchestration. The CVE description specifically calls out network-namespace cleanup and interface destruction, both of which can occur without an operator manually taking down an HSR link.

That puts the practical exposure in a smaller group than the headline “Linux kernel CVE” might imply:

• Industrial control, manufacturing, power, transportation, and edge deployments using HSR or PRP topology are the clearest candidates.
• Appliances and embedded systems that recreate network namespaces or HSR member interfaces repeatedly can accumulate leaked allocations over time.
• Container hosts are only relevant if their networking stack actually uses the HSR driver and the affected teardown sequence; ordinary container networking does not become vulnerable merely because HSR support exists in the kernel.
• Standard desktops, ordinary Linux servers, and most cloud VMs are unlikely to exercise this code at all.

The presence of an HSR-capable kernel is not enough. An administrator normally creates an HSR device explicitly with an

command and supplies two slave interfaces. The setup also requires elevated network-administration privileges. The record does not show a path in which an unauthenticated network peer can induce the leak merely by sending traffic to a machine.

For security teams, that changes priority. CVE-2026-68301 belongs in kernel maintenance and reliability tracking, especially for HSR deployments, but the published evidence does not support treating it as an emergency remote-compromise flaw.

The published version data contains a material contradiction​

The CVE’s affected-package data identifies

and names upstream fixes in the active stable series: 6.6.148, 6.12.101, 6.18.42, and 7.1.6. It also lists 7.2-rc5 as the upstream point at which the mainline tree is unaffected. Those are the usable remediation markers for administrators choosing a maintained kernel.

But the same record includes conflicting claims about older releases. One range says Linux 5.15.194 through the end of the 5.15 series and Linux 6.1.153 through the end of the 6.1 series are affected. Elsewhere in the same affected record, the data says versions below Linux 6.13 are unaffected.

Both statements cannot be true as written.

The safer reading is to avoid treating the 5.15 and 6.1 entries as a confirmed exposure determination until kernel.org corrects or clarifies the CVE JSON. The version conflict may reflect a problem in the way commit ancestry and semantic-version ranges were encoded rather than in the patch itself, but an administrator should not have to reverse-engineer that distinction from a vulnerability record.

This is also why “updated to the latest supported kernel” is better advice than attempting to determine exposure from a version string alone. Vendor kernels routinely carry backports, extra patches, and version suffixes that do not map cleanly to upstream releases. A distribution’s security advisory or changelog is the authoritative source for whether its specific package incorporates the change.

Windows and WSL 2 require a separate check​

Native Windows networking does not include the Linux

code, so CVE-2026-68301 does not require a Windows Update response. The relevant Windows case is WSL 2, which runs a real Linux kernel in a managed virtual machine, as well as Hyper-V, VMware, or other Linux guest deployments hosted on Windows.

Microsoft’s WSL documentation confirms that WSL 2 uses a Microsoft-built Linux kernel, and it also permits a custom kernel through the

setting in

. Those two facts create different patch paths. A standard WSL 2 installation depends on Microsoft shipping or backporting the repair; a WSL setup configured with a custom kernel depends on the person or organization maintaining that image.

No Microsoft advisory or WSL release note is referenced in the CVE record. More importantly, the upstream fixed-version list does not prove that a WSL kernel with a different version label lacks—or includes—the patch. Administrators with custom WSL kernels should check

, identify the source branch and patch set used to build it, and search that source tree for the

cleanup in

.

For an initial exposure screen on a Linux host or guest, these checks separate “kernel has HSR support” from “system is actually using it”:

uname -r
lsmod | grep '^hsr'
ip -d link show type hsr

A loaded

module alone does not demonstrate the vulnerable path has run. An active HSR interface with member devices that are dynamically removed, especially in namespace-heavy or automated environments, is the configuration worth investigating.

Patch the HSR systems, but do not inflate the threat model​

The clean fix is to update to the first patched kernel package supplied by the platform vendor, then reboot into it or use the organization’s approved live-patching process where available. Operators who build their own kernels should apply the upstream cleanup change and validate interface removal in the same HSR and VLAN configuration used in production.

The CVE record’s lack of a severity score is not a reason to ignore it. Memory leaks in persistent infrastructure can become availability incidents after enough interface churn, and HSR is generally deployed precisely where network continuity matters. But the absence of a demonstrated remote trigger, memory-safety corruption primitive, or confidentiality impact should keep the response proportional.

The remaining item to watch is the version metadata. Until kernel.org reconciles the contradiction between the 5.15/6.1 ranges and its statement that releases before 6.13 are unaffected, teams running those older long-term-support kernels should rely on their distribution’s package advisory and the presence of the actual patch—not the CVE’s current range field alone.