CVE-2025-37865

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported<br /> <br /> Russell King reports that on the ZII dev rev B, deleting a bridge VLAN<br /> from a user port fails with -ENOENT:<br /> https://lore.kernel.org/netdev/Z_lQXNP0s5-IiJzd@shell.armlinux.org.uk/<br /> <br /> This comes from mv88e6xxx_port_vlan_leave() -&gt; mv88e6xxx_mst_put(),<br /> which tries to find an MST entry in &amp;chip-&gt;msts associated with the SID,<br /> but fails and returns -ENOENT as such.<br /> <br /> But we know that this chip does not support MST at all, so that is not<br /> surprising. The question is why does the guard in mv88e6xxx_mst_put()<br /> not exit early:<br /> <br /> if (!sid)<br /> return 0;<br /> <br /> And the answer seems to be simple: the sid comes from vlan.sid which<br /> supposedly was previously populated by mv88e6xxx_vtu_get().<br /> But some chip-&gt;info-&gt;ops-&gt;vtu_getnext() implementations do not populate<br /> vlan.sid, for example see mv88e6185_g1_vtu_getnext(). In that case,<br /> later in mv88e6xxx_port_vlan_leave() we are using a garbage sid which is<br /> just residual stack memory.<br /> <br /> Testing for sid == 0 covers all cases of a non-bridge VLAN or a bridge<br /> VLAN mapped to the default MSTI. For some chips, SID 0 is valid and<br /> installed by mv88e6xxx_stu_setup(). A chip which does not support the<br /> STU would implicitly only support mapping all VLANs to the default MSTI,<br /> so although SID 0 is not valid, it would be sufficient, if we were to<br /> zero-initialize the vlan structure, to fix the bug, due to the<br /> coincidence that a test for vlan.sid == 0 already exists and leads to<br /> the same (correct) behavior.<br /> <br /> Another option which would be sufficient would be to add a test for<br /> mv88e6xxx_has_stu() inside mv88e6xxx_mst_put(), symmetric to the one<br /> which already exists in mv88e6xxx_mst_get(). But that placement means<br /> the caller will have to dereference vlan.sid, which means it will access<br /> uninitialized memory, which is not nice even if it ignores it later.<br /> <br /> So we end up making both modifications, in order to not rely just on the<br /> sid == 0 coincidence, but also to avoid having uninitialized structure<br /> fields which might get temporarily accessed.