Cloudanix VulnDB

CVE-2026-68301

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's high-availability networking code can slowly leak memory when network interfaces are added or removed, which may eventually slow down or destabilize the system.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The flaw is a memory leak in the Linux kernel HSR driver: hsr_del_port() fails to call vlan_vids_del_by_dev when a slave is unregistered, leaving vlan_vid_info structures (for VID 0 and other synced VLANs) with elevated refcounts that are never released on slave destruction.

Why it matters to the business

Systems running HSR (common in industrial and high-availability networks) can suffer gradual kernel memory exhaustion during interface churn or network-namespace cleanup, leading to performance degradation, OOM kills, or eventual system instability; urgency is low given the absence of known exploitation.

How an attack unfolds

An attacker with local or container-level network privileges repeatedly brings HSR masters up (triggering auto-add of VID 0 to slaves) then destroys or moves slave interfaces, causing hsr_del_port() to leak vlan structures each time; repeated cycles accumulate unreclaimed memory until kernel resources are exhausted.

How to fix it

Apply the upstream fix that adds vlan_vids_del_by_dev(port->dev, master->dev) inside hsr_del_port() before unlinking slaves; rebuild and deploy the patched kernel on all affected hosts.

How to confirm the fix worked

Inspect the hsr_del_port() implementation for the vlan_vids_del_by_dev call; reproduce the leak scenario in a test namespace and confirm that slave destruction no longer leaves vlan_info structures allocated.

Typical attack path

  1. Obtain ability to create or manipulate network namespaces or interfaces
  2. Create HSR master device and attach slave interfaces
  3. Bring the master up so vlan_vid_add propagates VID 0 to slaves
  4. Unregister or destroy a slave (or move it between namespaces) to invoke hsr_del_port() without VLAN cleanup
  5. Repeat the cycle to accumulate leaked vlan_vid_info allocations

How to detect it

Watch for repeated HSR slave addition/removal events in kernel logs while tracking kmemleak or slabinfo growth in vlan-related caches; correlate with netns or interface destruction activity.

What your security team should do

  • Prioritize kernel updates on systems that use HSR or PRP redundancy protocols
  • Restrict unprivileged users and containers from creating or destroying network interfaces
  • Monitor kernel slab or kmemleak reports for growth in vlan_vid_info objects on HSR hosts
  • Document HSR usage and schedule patching within normal kernel maintenance windows

The record

In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.

Affected packages

Ecosystem Package Introduced Fixed