Hi all, MST can be enabled while VLAN filtering is disabled and no port VLAN entries exist. nbp_vlan_init() still installs a port VLAN group, so br_mst_is_enabled() returns true even though BROPT_VLAN_ENABLED is off.
With that configuration: ingress skips the normal p->state check and forces forwarding br_allowed_ingress() accepts the unfiltered frame br_allowed_egress() accepts the unfiltered frame A port in BR_STATE_BLOCKING therefore still forwards data in both directions. STP/MRP loop protection is defeated. Observed on Linux v7.3, commit 08ab31164c55f20c7a2653de3186ae333470e2c1, with vlan_filtering=0, default_pvid=0, mst_enabled=1, and a port whose IFLA_BRPORT_STATE read back as BR_STATE_BLOCKING: MST on: egress=3 ingress=3 MST off: egress=0 ingress=0 MST on: egress=3 ingress=3 Each direction sent three matching broadcast frames. This is a deterministic configuration/state mismatch, not a race. The MST fast path should require both MST and VLAN filtering, while retaining the existing non-NULL port VLAN-group lifetime check. The MST configuration itself should also be rejected if it is unusable with VLAN filtering disabled. CVE-2025-40297 used the same broad predicate for a port-deletion UAF, but its fix only added the vlgrp lifetime check. The normal data-plane forwarding bypass remains in current source; I found no separate fix or CVE. The test used a diagnostic switchdev endpoint only to establish the MRP ring state. It did not replace bridge, VLAN, MST or packet-forwarding code. The PoC and full program/console logs are available on request. This was found with a multi-agent workflow; the forwarding differential was reproduced in QEMU. Thanks, Cheng Yongkang
