[BUG] net: bridge: MST bypasses blocking when VLAN filtering is off

[BUG] net: bridge: MST bypasses blocking when VLAN filtering is off

[Cheng Yongkang]

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