Re: [PATCH net] bridge: cfm: Fix race condition in peer_mep deletion

Hyunwoo Kim <[email protected]>
Newsgroups gmane.linux.network.bridge,gmane.linux.network
Message-ID <abDbPJ5nZ1u9fZRi@v4bel>
On Wed, Mar 11, 2026 at 03:18:09AM +0900, Hyunwoo Kim wrote:
> When a peer MEP is being deleted, cancel_delayed_work_sync() is called
> on ccm_rx_dwork before freeing. However, br_cfm_frame_rx() runs in
> softirq context under rcu_read_lock (without RTNL) and can re-schedule
> ccm_rx_dwork via ccm_rx_timer_start() between cancel_delayed_work_sync()
> returning and kfree_rcu() being called.
> 
> The following is a simple race scenario:
> 
>            cpu0                                     cpu1
> 
> mep_delete_implementation()
>   cancel_delayed_work_sync(ccm_rx_dwork);
>                                            br_cfm_frame_rx()
>                                              // peer_mep still in hlist
>                                              if (peer_mep->ccm_defect)
>                                                ccm_rx_timer_start()
>                                                  queue_delayed_work(ccm_rx_dwork)
>   hlist_del_rcu(&peer_mep->head);
>   kfree_rcu(peer_mep, rcu);
>                                            ccm_rx_work_expired()
>                                              // on freed peer_mep
> 
> To prevent this, cancel_delayed_work_sync() is replaced with
> disable_delayed_work_sync() in both peer MEP deletion paths, so
> that subsequent queue_delayed_work() calls from br_cfm_frame_rx()
> are silently rejected.
> 
> The cc_peer_disable() helper retains cancel_delayed_work_sync()
> because it is also used for the CC enable/disable toggle path where
> the work must remain re-schedulable.
> 
> Fixes: dc32cbb3dbd7 ("bridge: cfm: Kernel space implementation of CFM. CCM frame RX added.")
> Signed-off-by: Hyunwoo Kim <[email protected]>
> ---
>  net/bridge/br_cfm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/bridge/br_cfm.c b/net/bridge/br_cfm.c
> index 2c70fe47de38..118c7ea48c35 100644
> --- a/net/bridge/br_cfm.c
> +++ b/net/bridge/br_cfm.c
> @@ -576,7 +576,7 @@ static void mep_delete_implementation(struct net_bridge *br,
>  
>  	/* Empty and free peer MEP list */
>  	hlist_for_each_entry_safe(peer_mep, n_store, &mep->peer_mep_list, head) {
> -		cancel_delayed_work_sync(&peer_mep->ccm_rx_dwork);
> +		disable_delayed_work_sync(&peer_mep->ccm_rx_dwork);
>  		hlist_del_rcu(&peer_mep->head);
>  		kfree_rcu(peer_mep, rcu);
>  	}
> @@ -732,7 +732,7 @@ int br_cfm_cc_peer_mep_remove(struct net_bridge *br, const u32 instance,
>  		return -ENOENT;
>  	}
>  
> -	cc_peer_disable(peer_mep);
> +	disable_delayed_work_sync(&peer_mep->ccm_rx_dwork);
>  
>  	hlist_del_rcu(&peer_mep->head);
>  	kfree_rcu(peer_mep, rcu);
> -- 
> 2.43.0
> 

CC'ing the Fixes patch authors and Sabrina, who is familiar with this bug pattern.


Best regards,
Hyunwoo Kim
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.