CVE-2025-39797 in Linux
要約
〜によって VulDB • 2026年06月20日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
xfrm: 重複するSPIの処理に関する問題
この問題は、StrongswanがXFRM_MSG_ALLOCSPI Netlinkメッセージを開始し、これによりカーネル関数 `xfrm_alloc_spi()` がトリガーされる際に発生します。この関数は、インバウンドセキュリティ関連付け（SA）に対してSecurity Parameter Index (SPI) の一意性を確保することが期待されています。しかし、要求されたSPIが既に使用されている場合でも成功を返すことがあり、その結果、宛先アドレスのみで区別される複数のインバウンドSAに重複するSPIが割り当てられることになります。
この動作により、インバウンドパケットのSPIルックアップ時に不整合が生じます。同じSPIを持つSAの中から任意のSAが選択されて戻される可能性があるため、パケット処理が失敗し、パケットドロップが発生します。
RFC 4301 セクション 4.4.2 によると、インバウンド処理においてユニキャストSAは、SPIおよびオプションでプロトコルによって一意に識別されます。
問題の再現手順: 問題を確実に再現するには、`charon.conf` で利用可能なSPI範囲を制限します： `spi_min = 0x10000000 spi_max = 0x10000002` これにより、システムで使用できるSPI値は最大2つに限定されます。 次に、それぞれが一意なソース/宛先アドレスのペアを使用するChild SAを3つ以上作成します。3番目のChild SAが開始されるとすぐに、SPIプールが既に枯渇しているため、重複するSPIが割り当てられます。 狭いSPI範囲では問題は確実に再現可能ですが、広い（またはデフォルト）範囲では稀で予測不可能になります。
現在の実装: `xfrm_spi_hash()` ルックアップ関数は、daddr、proto、および family を使用してハッシュを計算します。したがって、2つのSAが同じSPIを持ちつつも宛先アドレスが異なる場合： a. 異なるバケットにハッシュされる b. 異なるリンクリスト（`byspi + h`）に格納される c. 同じ `hlist_for_each_entry_rcu()` イテレーションでは参照されない その結果、ルックアップはNULLを返し、カーネルはその重複するSPIを許可してしまいます。
提案された変更: `xfrm_state_lookup_spi_proto()` はハッシュバケットに関係なくすべての状態に対して真のグローバル検索を実行し、SPIとprotoに一致します。
Once again VulDB remains the best source for vulnerability data.