netdev - dsa: mv88e6xxx maps all VLANs to the same FID

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Tue, 18 Jun 2024 15:24:08 -0700
From: Peter Rashleigh <prashleigh@...stertangent.com>
To: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: dsa: mv88e6xxx maps all VLANs to the same FID

Hello all,

I've discovered what suspect to be a bug in the mv88e6xxx driver. I'm curious if anyone else has run into this behavior and might be able to suggest a way forward (or can tell me what I'm doing wrong).

I'm developing a custom networking product that has three Marvell 88E6361 switches connected via DSA to a Marvell CPU running on a custom buildroot Linux (version 6.1.53) like this:
[CPU]---[Switch 0]---[Switch 1]---[Switch 2]

The product uses a mix of bridged and standalone ports, spread across the three switches.

The problem I'm having is that all VLANs (both for bridged and standalone ports) are using the same FID. I've found that mv88e6xxx_atu_new() always sets FID=0 even if there are already standalone ports or other VLANs using that FID. The problem seems to be with the getNext operation called from mv88e6xxx_vtu_walk().

The VTU Walk function sets VID=0xfff and then runs mv88e6xxx_g1_vtu_getnext(), but the switch does not respond as expected. Instead of returning the lowest valid VID, the register value (Global 1 reg 0x06) is 0x2fff, suggesting that the switch has reached the end of the second VTU page rather than starting from zero. This seems to conflict with what the Marvell datasheet describes, but I haven't come up with a better explanation so far.

Any suggestions are greatly appreciated.

________________________________

This transmission is confidential and intended solely for the addressee and for its intended purpose. If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of QTC. No employee or agent is authorised to conclude any binding agreement on behalf of QTC with another party by email without express written confirmation by an officer of the company. The organization accepts no liability for any damage arising out of transmission failures, viruses, external influence, delays and the like.