CVE-2025-37865 in Linux
Summary
by MITRE • 05/09/2025
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported
Russell King reports that on the ZII dev rev B, deleting a bridge VLAN from a user port fails with -ENOENT: https://lore.kernel.org/netdev/[email protected]/
This comes from mv88e6xxx_port_vlan_leave() -> mv88e6xxx_mst_put(), which tries to find an MST entry in &chip->msts associated with the SID, but fails and returns -ENOENT as such.
But we know that this chip does not support MST at all, so that is not surprising. The question is why does the guard in mv88e6xxx_mst_put() not exit early:
if (!sid) return 0;
And the answer seems to be simple: the sid comes from vlan.sid which supposedly was previously populated by mv88e6xxx_vtu_get(). But some chip->info->ops->vtu_getnext() implementations do not populate vlan.sid, for example see mv88e6185_g1_vtu_getnext(). In that case, later in mv88e6xxx_port_vlan_leave() we are using a garbage sid which is just residual stack memory.
Testing for sid == 0 covers all cases of a non-bridge VLAN or a bridge VLAN mapped to the default MSTI. For some chips, SID 0 is valid and installed by mv88e6xxx_stu_setup(). A chip which does not support the STU would implicitly only support mapping all VLANs to the default MSTI, so although SID 0 is not valid, it would be sufficient, if we were to zero-initialize the vlan structure, to fix the bug, due to the coincidence that a test for vlan.sid == 0 already exists and leads to the same (correct) behavior.
Another option which would be sufficient would be to add a test for mv88e6xxx_has_stu() inside mv88e6xxx_mst_put(), symmetric to the one which already exists in mv88e6xxx_mst_get(). But that placement means the caller will have to dereference vlan.sid, which means it will access uninitialized memory, which is not nice even if it ignores it later.
So we end up making both modifications, in order to not rely just on the sid == 0 coincidence, but also to avoid having uninitialized structure fields which might get temporarily accessed.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 01/31/2026
The vulnerability CVE-2025-37865 affects the Linux kernel's DSA subsystem, specifically within the mv88e6xxx switch driver implementation. This issue manifests when attempting to delete bridge VLANs from user ports on certain hardware platforms, particularly the ZII dev rev B. The problem stems from a fundamental flaw in how the driver handles MST (Multiple Spanning Tree) entries during VLAN deletion operations, creating a scenario where the system returns an incorrect -ENOENT error code instead of gracefully handling the operation.
The technical root cause lies in the mv88e6xxx_port_vlan_leave() function which calls mv88e6xxx_mst_put() to clean up MST entries associated with a VLAN. However, the driver fails to properly validate that the chip actually supports MST functionality before attempting to process MST entries. This is particularly problematic because the affected hardware does not support MST at all, yet the code attempts to perform MST operations that would logically fail. The vulnerability occurs when the vlan.sid field, which should contain the spanning tree identifier, is not properly populated by the vtu_getnext() implementation for certain chip variants like mv88e6185_g1_vtu_getnext(), resulting in the use of garbage stack memory values.
The operational impact of this vulnerability extends beyond simple error reporting, as it can cause bridge VLAN deletion operations to fail completely, potentially leading to network connectivity issues and configuration management problems in switch-based network environments. This affects network infrastructure devices that rely on the mv88e6xxx switch driver for their operation, particularly those using hardware platforms where MST functionality is not supported but the driver code does not properly account for this limitation. The vulnerability represents a classic case of improper initialization and validation, where uninitialized memory values are used in conditional logic without proper bounds checking.
The mitigation strategy involves implementing two key modifications to ensure proper handling of the MST entry cleanup process. First, the code must properly initialize the VLAN structure to avoid relying on coincidental behavior where sid == 0 might appear to work correctly, but actually depends on uninitialized memory values. Second, the driver should implement explicit checks for MST support capabilities using existing functions like mv88e6xxx_has_stu() before attempting MST operations. This approach aligns with security best practices and follows the principle of least privilege by ensuring that operations are only performed when the underlying hardware actually supports them. The fix addresses the underlying CWE-457 issue of uninitialized variables and prevents potential information disclosure or denial of service scenarios that could arise from improper error handling in network switch drivers. This vulnerability demonstrates the importance of proper hardware capability detection and validation in embedded networking systems, particularly in environments where multiple chip variants with different feature sets are supported by a single driver implementation. The solution ensures that the driver behaves correctly regardless of the specific hardware platform while maintaining compatibility with both supported and unsupported MST configurations through proper conditional logic and initialization patterns.