CVE-2026-98549 in Linux
Riassunto
di VulDB • 18/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
tcp: prevenire il collasso degli skbs oltre i limiti nella coda rtx
tcp_write_collapse_fence() imposta TCP_SKB_CB(skb)->eor = 1 su tcp_write_queue_tail(sk) per impedire che gli skbs accodati dopo un passaggio alla crittografia del dispositivo vengano fusi (collapsed) con gli skbs precedenti.
Il fence è una no-op se tutti i dati precedenti sono già stati trasmessi quando avviene il cambio: la coda di scrittura sk->sk_write_queue è vuota. Gli skbs precedenti non ancora riconosciuti restano in attesa nella sk->tcp_rtx_queue con eor = 0.
In caso di ritrasmissione successiva o spostamento SACK, tcp_retrans_try_collapse() o tcp_shift_skb_data() possono quindi fondere un skb accodato dopo il passaggio in uno accodato prima del passaggio.
Entrambi gli utenti del fence sono interessati:
- psp: i dispositivi crittografano solo gli skbs con skb->decrypted impostato. L'skb fuso mantiene decrypted = 0 dall'skb precedente, quindi i dati inviati dopo psp_sock_assoc_set_tx() vengono ritrasmessi in chiaro.
- tls device offload: l'skb fuso si estende oltre il marker di inizio impostato in tls_set_device_offload(). Il fallback software (fill_sg_in() restituisce -EINVAL) e i driver mlx5, nfp e funeth non possono gestire un tale skb e lo scartano. Ogni ritrasmissione ricrea lo stesso skb, causando l'interruzione della connessione.
Risolvere il problema in due punti, per una difesa in profondità:
1. Effettuare il fallback su tcp_rtx_queue_tail(sk) in tcp_write_collapse_fence() quando tcp_write_queue_tail(sk) è NULL.
2. Verificare !skb_cmp_decrypted(to, from) in tcp_skb_can_collapse(), come fa tcp_skb_can_collapse_rx() durante la ricezione. skb_shift(), che viene chiamato da entrambi i percorsi di collasso, ha già un DEBUG_NET_WARN_ON_ONCE() per questa condizione.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.