CVE-2026-68301
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.
Executive briefing
The source record describes: 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. The practical risk depends on whether an affected product/version is present, reachable and configured in an exploitable way. Review the affected-product evidence and linked vendor advisories before assigning exposure status.
Evidence confidence: Limited Evidence-derived, not an exploitability verdict
Severity & attack characteristics
CVSS vector:
No CVSS vector is currently available in the source record.
Technical explanation & impact
The technical mechanism is not expanded beyond the source description unless a referenced advisory supplies additional evidence. Read the linked vendor/CERT advisories for root-cause detail.
Potential impact must be interpreted from the published CVSS impact metrics and the affected component. A CVSS impact score is not proof that a particular asset is exploitable.
Affected products and versions
NVD has not supplied machine-readable vulnerable CPE product/version entries for this CVE. This is an information gap, not proof that no products are affected. Check the vendor advisory references below.
Remediation & validation
- Identify exposure by comparing the affected product and version ranges with your asset inventory, SBOM and externally exposed services.
- Review the linked vendor security advisory or patch notes. Upgrade to a vendor-confirmed fixed release; do not infer a fixed version from the CVE description.
- Until patched, consider restricting network access or disabling the affected feature where operationally safe. These are temporary controls, not a substitute for a vendor fix.
- Validate the remediation with a version check and vulnerability rescan, then retain change evidence.
No fixed version is displayed unless it is explicitly established by a vendor advisory. Follow the vendor's release notes for exact product and branch applicability.
Vendor advisories, patches & exploit references
- https://git.kernel.org/stable/c/21d48408479a17eb65568a765930adea37e4d804 REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- https://git.kernel.org/stable/c/79ff0547676acdeceda445c3fce4071b0a887b70 REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- https://git.kernel.org/stable/c/ae995b8002d3af134560a706c0e111a89e26317c REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- https://git.kernel.org/stable/c/b5ded444621b6180df9f3d4e07045fc1fc1e8cd9 REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- https://git.kernel.org/stable/c/ccc822e9e4f09a6c2ca73ad5334570441947f94f REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- https://git.kernel.org/stable/c/dcf15eaf5641812f1cfc5e96537380132a7da89d VENDOR 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- https://git.kernel.org/stable/c/f72c312af6c7897ab0f8a2b5a63f917a207a4143 REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Information gaps & confidence notes
These gaps indicate missing source data. CVE Watch does not fill them with guessed product, exploit or patch details.
- NVD does not currently provide machine-readable vulnerable CPE product/version entries for this record.
- No CVSS vector is currently available in the source record.
- No CWE classification is currently available.
Last enrichment: 2026-11-07T16:31:34+00:00 · Source last modified: 2026-11-06T17:19:28.183