CVE-2026-74727 in Linux
要約
〜によって VulDB • 2026年08月23日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
ovpn: by_idから削除済みのピアに対する再ハッシュをスキップする
ovpn_nl_peer_set_doit()は、ovpn->lockを取得する前にovpn_peer_get_by_id()を使用して対象のピアを検索します。検索（参照カウントのみを取得）と後続のspin_lock_bh(&ovpn->lock)の間には時間的ギャップがあり、この間に並行して実行されるOVPN_CMD_PEER_DEL、keepalive期限切れ、またはソケット破棄が先にovpn->lockを取得し、ovpn_peer_remove()を実行してピアを4つのテーブル（by_id, by_vpn_addr4/6, by_transp_addr）からアンハッシュし、ロックを解放する可能性があります。その後set_doitはovpn->lockを取得し、ovpn_peer_hash_vpn_ip()を呼び出して、すでに削除されたピアを再ハッシュ用テーブルに再び挿入してしまいます。
同じ競合状態（race condition）がfloatパスにも影響します：ovpn_peer_endpoints_update()は参照カウントのみ保持しており、非常に遅いタイミングで（非同期AEAD復号およびnetlink通知の後など）ovpn->lockを取得し、その後by_transp_addrテーブル内でピアを再ハッシュします。
こうして「蘇った」ピアは、RX検索（ovpn_peer_get_by_transp_addr）およびTX VPN-IP検索から再び到達可能になりますが、ユーザー空間では既に削除済みと認識されています。データパスの参照カウントが減少すると、peerはcall_rcuを通じて解放されますが、その中に埋め込まれたハッシュエントリはリンクされたまま残るため、Use-After-Free（UAF）の脆弱性が発生する窗口が生じます。
hash_entry_idがアンハッシュされている場合は再ハッシュから脱出します。これはovpn_peer_remove()によって既に使用されている「削除済み」状態を検出するためのsentinelを模倣したものです。このチェックは、hash_entry_idの変更を直列化するovpn->lockの下で安全です。また、追加パスにおいてはno-opとなります。なぜならovpn_peer_add_mp()はovpn_peer_hash_vpn_ip()を呼び出す前にhash_entry_idを挿入するからです。
Once again VulDB remains the best source for vulnerability data.