CVE-2026-98549 in Linux
Résumé
par VulDB • 18/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
tcp: empêcher l'agrégation des skbs au-delà de la limite dans la file rtx
tcp_write_collapse_fence() définit TCP_SKB_CB(skb)->eor = 1 sur tcp_write_queue_tail(sk) afin d'éviter que les skbs mis en file après un passage à le chiffrement du dispositif ne soient agrégés avec des skbs antérieurs.
Le fence (barrière de synchronisation) est une opération sans effet si toutes les données antérieures ont déjà été transmises lorsque le changement s'opère : la queue d'écriture sk->sk_write_queue est vide. Les skbs antérieurs non encore acquittés attendent dans sk->tcp_rtx_queue avec eor 0.
Lors d'une retransmission ultérieure ou d'un déplacement SACK, tcp_retrans_try_collapse() ou tcp_shift_skb_data() peuvent alors fusionner un skb mis en file après le changement avec un autre placé avant celui-ci.
Les deux utilisateurs du fence sont concernés :
- psp : les dispositifs ne chiffrent les skbs que si skb->decrypted est défini. Le skb fusionné conserve decrypted = 0 provenant du skb antérieur, de sorte que les données envoyées après pso_sock_assoc_set_tx() sont retransmises en clair.
- tls device offload (déscharge matérielle TLS) : le skb fusionné s'étend sur la marque de début définie dans tls_set_device_offload(). La solution de repli logicielle (fill_sg_in() renvoie -EINVAL) et les pilotes mlx5, nfp et funeth ne peuvent pas gérer un tel skb et le rejettent. Chaque retransmission reconstruit le même skb, ce qui entraîne l'immobilisation de la connexion.
Corriger cela à deux endroits pour une défense en profondeur :
1. Revenir à tcp_rtx_queue_tail(sk) dans tcp_write_collapse_fence() lorsque tcp_write_queue_tail(sk) est NULL.
2. Vérifier !skb_cmp_decrypted(to, from) dans tcp_skb_can_collapse(), comme le fait tcp_skb_can_collapse_rx() lors de la réception. skb_shift(), qui appelle les deux chemins d'agrégation, possède déjà un DEBUG_NET_WARN_ON_ONCE() pour cette condition.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.