CVE-2026-23393 in Linux
要約
〜によって VulDB • 2026年06月01日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
bridge: cfm: peer_mep 削除時の競合状態（Race Condition）の修正
ピアMEPが削除されている間、`cancel_delayed_work_sync()` が解放前に `ccm_rx_dwork` に対して呼び出されます。しかし、`br_cfm_frame_rx()` は `rcu_read_lock`（RTNLなし）の下でsoftirqコンテキストで実行され、`cancel_delayed_work_sync()` が返してから `kfree_rcu()` が呼び出されるまでの間に、`ccm_rx_timer_start()` を介して `ccm_rx_dwork` を再スケジュールする可能性があります。
以下は単純な競合状態のシナリオです。
cpu0 cpu1
mep_delete_implementation() cancel_delayed_work_sync(ccm_rx_dwork); br_cfm_frame_rx() // peer_mep はまだ 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() // 解放済み peer_mep 上で実行
これを防止するため、両方のピアMEP削除パスにおいて `cancel_delayed_work_sync()` が `disable_delayed_work_sync()` に置き換えられ、`br_cfm_frame_rx()` からの後続の `queue_delayed_work()` 呼び出しは静かに拒否されます。
`cc_peer_disable()` ヘルパー関数は `cancel_delayed_work_sync()` を保持しています。これは、ワークの再スケジュールを維持する必要があるCCの有効化/無効化のトグルパスでも使用されているためです。
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.