Question: bridge: clarify MST VLAN list RCU traversal contract

Question: bridge: clarify MST VLAN list RCU traversal contract

[Runyu Xiao]

Hi bridge maintainers,

This question comes from a candidate found by our static analysis tool
and then manually reviewed against the current tree. The audit used
CONFIG_PROVE_RCU_LIST as target-matched triage evidence; I am asking
for maintainer guidance because the source-level review did not prove
a use-after-free.

A CONFIG_PROVE_RCU_LIST audit flags the VLAN-list traversal in
br_mst_info_size():

  net/bridge/br_mst.c:251 br_mst_info_size()

The helper walks vg->vlan_list with list_for_each_entry_rcu().  In the
direct local context, br_get_link_af_size_filtered() first enters an
RCU read-side section, resolves the bridge port or bridge VLAN group,
and calls br_get_num_vlan_infos(vg, filter_mask).  That local RCU
read-side section is then dropped before the later MST sizing call:

  net/bridge/br_netlink.c:104 rcu_read_lock()
  net/bridge/br_netlink.c:113 br_get_num_vlan_infos(vg, filter_mask)
  net/bridge/br_netlink.c:114 rcu_read_unlock()
  net/bridge/br_netlink.c:123 br_mst_info_size(vg)

The helper is registered through rtnl_af_ops.get_link_af_size, and
bridge VLAN updates appear RTNL-centered, so the broader rtnetlink
sizing path may already provide the intended serialization.  I am not
claiming a use-after-free here.  The question is only whether the
RCU-list traversal contract around br_mst_info_size() should be made
explicit enough for CONFIG_PROVE_RCU_LIST to see it.

Would you prefer one of these directions?

  1. keep the MST sizing loop inside an explicit rcu_read_lock() in
     br_get_link_af_size_filtered();

  2. pass a confirmed RTNL lockdep condition to the iterator in
     br_mst_info_size();

  3. document that the outer rtnetlink sizing path is the required
     protection and leave the helper unchanged;

  4. use a different bridge-specific pattern.

I am intentionally sending this as a maintainer question rather than a
patch because the right contract seems to depend on the bridge/rtnetlink
caller semantics.

Thanks.

Re: Question: bridge: clarify MST VLAN list RCU traversal contract

[Ido Schimmel]

On Sat, Jun 27, 2026 at 09:25:39PM +0800, Runyu Xiao wrote:
> Hi bridge maintainers,
> 
> This question comes from a candidate found by our static analysis tool
> and then manually reviewed against the current tree. The audit used
> CONFIG_PROVE_RCU_LIST as target-matched triage evidence; I am asking
> for maintainer guidance because the source-level review did not prove
> a use-after-free.
> 
> A CONFIG_PROVE_RCU_LIST audit flags the VLAN-list traversal in
> br_mst_info_size():
> 
>   net/bridge/br_mst.c:251 br_mst_info_size()
> 
> The helper walks vg->vlan_list with list_for_each_entry_rcu().  In the
> direct local context, br_get_link_af_size_filtered() first enters an
> RCU read-side section, resolves the bridge port or bridge VLAN group,
> and calls br_get_num_vlan_infos(vg, filter_mask).  That local RCU
> read-side section is then dropped before the later MST sizing call:
> 
>   net/bridge/br_netlink.c:104 rcu_read_lock()
>   net/bridge/br_netlink.c:113 br_get_num_vlan_infos(vg, filter_mask)
>   net/bridge/br_netlink.c:114 rcu_read_unlock()
>   net/bridge/br_netlink.c:123 br_mst_info_size(vg)
> 
> The helper is registered through rtnl_af_ops.get_link_af_size, and
> bridge VLAN updates appear RTNL-centered, so the broader rtnetlink
> sizing path may already provide the intended serialization.  I am not
> claiming a use-after-free here.  The question is only whether the
> RCU-list traversal contract around br_mst_info_size() should be made
> explicit enough for CONFIG_PROVE_RCU_LIST to see it.
> 
> Would you prefer one of these directions?
> 
>   1. keep the MST sizing loop inside an explicit rcu_read_lock() in
>      br_get_link_af_size_filtered();
> 
>   2. pass a confirmed RTNL lockdep condition to the iterator in
>      br_mst_info_size();
> 
>   3. document that the outer rtnetlink sizing path is the required
>      protection and leave the helper unchanged;
> 
>   4. use a different bridge-specific pattern.
> 
> I am intentionally sending this as a maintainer question rather than a
> patch because the right contract seems to depend on the bridge/rtnetlink
> caller semantics.

I don't think anything needs to change. AFAICT, br_mst_info_size() is
only reachable via the get_link_af_size() callback and
rtnl_link_get_af_size() always invokes it from an RCU read-side critical
section.

Did you see a splat with CONFIG_PROVE_RCU_LIST?