The bridge-stp usermode helper is currently restricted to the initial
network namespace, preventing userspace STP daemons like mstpd from
operating on bridges in other namespaces. Since commit ff62198553e4
("bridge: Only call /sbin/bridge-stp for the initial network
namespace"), bridges in non-init namespaces silently fall back to
kernel STP with no way to request userspace STP.

This series adds a new IFLA_BR_STP_MODE bridge attribute that allows
explicit per-bridge control over STP mode selection. Three modes are
supported:

  - auto (default): existing behavior, try /sbin/bridge-stp in
    init_net, fall back to kernel STP otherwise
  - user: directly enable BR_USER_STP without invoking the helper,
    works in any network namespace
  - kernel: directly enable BR_KERNEL_STP without invoking the helper

The user and kernel modes bypass call_usermodehelper() entirely,
addressing the security concerns discussed at [1]. The caller is
responsible for managing the userspace STP daemon directly, rather
than relying on the kernel to invoke /sbin/bridge-stp.

Patch 1 adds the kernel support. The mode can only be changed while
STP is disabled and is processed before IFLA_BR_STP_STATE in
br_changelink() so both can be set atomically in a single netlink
message.

Patch 2 adds documentation for the new attribute in the bridge docs.

Patch 3 adds a selftest with 8 test cases. The test requires iproute2
with IFLA_BR_STP_MODE support and can be run with virtme-ng:

  vng --run arch/x86/boot/bzImage --skip-modules \
      --overlay-rwdir /sbin --overlay-rwdir /tmp --overlay-rwdir /bin \
      --exec 'cp /path/to/iproute2-next/ip/ip /bin/ip && \
              cd tools/testing/selftests/net && \
              bash bridge_stp_mode.sh'

iproute2 support can be found here [2].

[1] https://lore.kernel.org/netdev/565B7F7D.80208@nod.at/
[2] https://github.com/aroulin/iproute2-next/tree/bridge-stp-mode

Suggested-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Andy Roulin <aroulin@nvidia.com>

Andy Roulin (3):
  net: bridge: add stp_mode attribute for STP mode selection
  docs: net: bridge: document stp_mode attribute
  selftests: net: add bridge STP mode selection test

 Documentation/networking/bridge.rst           |  22 ++
 include/uapi/linux/if_link.h                  |  40 +++
 net/bridge/br_device.c                        |   1 +
 net/bridge/br_netlink.c                       |  18 +-
 net/bridge/br_private.h                       |   1 +
 net/bridge/br_stp_if.c                        |  17 +-
 tools/testing/selftests/net/Makefile          |   1 +
 .../testing/selftests/net/bridge_stp_mode.sh  | 261 ++++++++++++++++++
 8 files changed, 353 insertions(+), 8 deletions(-)
 create mode 100755 tools/testing/selftests/net/bridge_stp_mode.sh

--
2.43.0

On 24/03/2026 19:49, Andy Roulin wrote:
> The bridge-stp usermode helper is currently restricted to the initial
> network namespace, preventing userspace STP daemons like mstpd from
> operating on bridges in other namespaces. Since commit ff62198553e4
> ("bridge: Only call /sbin/bridge-stp for the initial network
> namespace"), bridges in non-init namespaces silently fall back to
> kernel STP with no way to request userspace STP.
> 
> This series adds a new IFLA_BR_STP_MODE bridge attribute that allows
> explicit per-bridge control over STP mode selection. Three modes are
> supported:
> 
>   - auto (default): existing behavior, try /sbin/bridge-stp in
>     init_net, fall back to kernel STP otherwise
>   - user: directly enable BR_USER_STP without invoking the helper,
>     works in any network namespace
>   - kernel: directly enable BR_KERNEL_STP without invoking the helper

I like that very much! This will also allow selftests for
switchdev/dsa drivers for correct (mst) STP state (change) handling.

> The user and kernel modes bypass call_usermodehelper() entirely,
> addressing the security concerns discussed at [1]. The caller is
> responsible for managing the userspace STP daemon directly, rather
> than relying on the kernel to invoke /sbin/bridge-stp.

Should the caller directly manage the STP daemon, or could the STP
daemon also just automatically manage bridges with
IFLA_BR_STP_STATE=BR_STP_MODE_KERNEL (and IFLA_BR_STP_STATE != 0)?

The latter would require less changes for network managers, as they
wouldn't need to be aware of (individual) STP daemon
implementations.

But I guess either is fine, as long as the latter behavior
configurable.

Best regards,
Jonas

On 3/25/26 00:28, Jonas Gorski wrote:
> On 24/03/2026 19:49, Andy Roulin wrote:
>> The bridge-stp usermode helper is currently restricted to the initial
>> network namespace, preventing userspace STP daemons like mstpd from
>> operating on bridges in other namespaces. Since commit ff62198553e4
>> ("bridge: Only call /sbin/bridge-stp for the initial network
>> namespace"), bridges in non-init namespaces silently fall back to
>> kernel STP with no way to request userspace STP.
>>
>> This series adds a new IFLA_BR_STP_MODE bridge attribute that allows
>> explicit per-bridge control over STP mode selection. Three modes are
>> supported:
>>
>>    - auto (default): existing behavior, try /sbin/bridge-stp in
>>      init_net, fall back to kernel STP otherwise
>>    - user: directly enable BR_USER_STP without invoking the helper,
>>      works in any network namespace
>>    - kernel: directly enable BR_KERNEL_STP without invoking the helper
> 
> I like that very much! This will also allow selftests for
> switchdev/dsa drivers for correct (mst) STP state (change) handling.
> 
>> The user and kernel modes bypass call_usermodehelper() entirely,
>> addressing the security concerns discussed at [1]. The caller is
>> responsible for managing the userspace STP daemon directly, rather
>> than relying on the kernel to invoke /sbin/bridge-stp.
> 
> Should the caller directly manage the STP daemon, or could the STP
> daemon also just automatically manage bridges with
> IFLA_BR_STP_STATE=BR_STP_MODE_KERNEL (and IFLA_BR_STP_STATE != 0)?
> 
> The latter would require less changes for network managers, as they
> wouldn't need to be aware of (individual) STP daemon
> implementations.
> 
> But I guess either is fine, as long as the latter behavior
> configurable.

STP daemons can listen to netlink and automatically discover the bridges
with IFLA_BR_STP_STATE=BR_STP_MODE_USER (or stp_state=BR_STP_USER).

Will change uapi doc in v2 from

  The caller is responsible for registering the bridge with the 
  

   userspace STP daemon after enabling STP, and for deregistering it 
  

   before disabling STP. 
  


to

   No /sbin/bridge-stp helper is invoked; userspace is responsible for 
  

   ensuring an STP daemon manages the bridge.