Detections
Analytics

Echo: linux: security update to 6.1.135-1

medium Tenable Self-Hosted Container Security Plugin ID 465157

Description

There are packages installed that are affected by a vulnerability referenced in the following CVE:

 - 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.
 (CVE-2025-37865)

Solution

Update the linux library and its related packages to version 6.1.135-1 or later.

See Also

https://advisory.echohq.com/cve/CVE-2025-37865

Plugin Details

Severity: Medium

ID: 465157

Version: Revision 1.1

Type: Local

Published: 10/2/2026

Updated: 10/2/2026

Risk Information

VPR

Risk Factor: Low

Score: 3

Percentile: 23.18

CVSS v2

Risk Factor: Medium

Base Score: 4.6

Temporal Score: 3.4

Vector: CVSS2#AV:L/AC:L/Au:S/C:N/I:N/A:C

CVSS Score Source: CVE-2025-37865

CVSS v3

Risk Factor: Medium

Base Score: 5.5

Temporal Score: 4.8

Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

Vulnerability Information

Exploit Ease: No known exploits are available

Patch Publication Date: 9/15/2025

Vulnerability Publication Date: 5/5/2025

Reference Information

CVE: CVE-2025-37865