CVE-2026-98549 in Linux
要約
〜によって VulDB • 2026年10月18日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
tcp: rtxキュー内の境界をまたぐskbsの結合（collapse）を防ぐ
`tcp_write_collapse_fence()`は、デバイス暗号化への切り替え後にキューに追加されたskbsが以前のskbsと結合されるのを防ぐために、`tcp_write_queue_tail(sk)`に対して `TCP_SKB_CB(skb)->eor = 1` を設定します。
このフェンス（境界線）は、切り替え時にそれ以前すべてのデータがすでに送信済みである場合（つまり `sk->sk_write_queue` が空の場合）、何もしない操作となります。まだACKされていない以前のskbsは `eor=0` の状態で `sk->tcp_rtx_queue` に待機しています。
その後の再送またはSACKシフトにおいて、`tcp_retrans_try_collapse()` または `tcp_shift_skb_data()` が、切り替え後にキューに追加されたskbを、それより前にキューに追加されたskbと結合してしまう可能性があります。
このフェンスを使用する両方のケースが影響を受けます：
- psp: デバイスは `skb->decrypted` が設定されているskbsのみを暗号化します。結合されたskbは、以前のskbから `decrypted=0` を維持するため、`psp_sock_assoc_set_tx()` 呼び出し後に送信されるデータはクリアテキストで再送されます。
- TLSデバイスオフロード: 結合されたskbは `tls_set_device_offload()` で設定された開始マーカーをまたぐことになります。ソフトウェアフォールバック（`fill_sg_in()` が `-EINVAL` を返す）およびmlx5、nfp、funethドライバではこのようなskbが処理できず、ドロップされます。再送のたびに同じskbが再生成されるため、接続がストールします。
これをディフェンス・イン・デプス（多層防御）のために2箇所で修正します：
1. `tcp_write_collapse_fence()` において、`tcp_write_queue_tail(sk)` がNULLの場合は `tcp_rtx_queue_tail(sk)` にフォールバックする。 2. `tcp_skb_can_collapse_rx()` で受信時に実行しているのと同様に、`tcp_skb_can_collapse()` 内で `!skb_cmp_decrypted(to, from)` をチェックする。両方の結合パスで呼び出される `skb_shift()` は、この条件に対してすでに `DEBUG_NET_WARN_ON_ONCE()` を持っています。
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.