CVE-2026-43503

Résumé

Dans le noyau Linux, la vulnérabilité suivante a été corrigée : net: skbuff: propager le marqueur de fragment partagé à travers les helpers de transfert de fragments. Deux helpers de transfert de fragments (__pskb_copy_fclone() et skb_shift()) ne propagent pas le bit SKBFL_SHARED_FRAG dans skb_shinfo()->flags lors du déplacement des fragments de la source vers la destination. __pskb_copy_fclone() délègue le reste des métadonnées shinfo à skb_copy_header() après avoir copié les descripteurs de fragments, mais ce helper ne reporte que gso_{size,segs, type} et ne touche jamais à skb_shinfo()->flags ; skb_shift() déplace directement les descripteurs de fragments et laisse les flags intacts. En conséquence, le skb de destination conserve une référence aux mêmes pages appartenant à un tiers ou adossées au cache de pages tout en indiquant que skb_has_shared_frag() est faux. Cette incohérence est nuisible dans tout code d'écriture en place qui utilise skb_has_shared_frag() pour décider si les pages partagées doivent être redirigées via skb_cow_data(). L'entrée ESP est un tel code (esp4.c, esp6.c), et une seule règle nft 'dup to <local>' — ou tout autre appelant de nf_dup_ipv4() / xt_TEE — suffit à faire atterrir un skb passé par pskb_copy() dans esp_input() avec le marqueur retiré, permettant à un utilisateur non privilégié d'écrire dans le cache de pages d'un fichier en lecture seule appartenant à root via des écritures parasites authencesn-ESN. Définissez SKBFL_SHARED_FRAG sur la destination chaque fois que des descripteurs de fragments ont effectivement été déplacés depuis la source. skb_copy() et skb_copy_expand() partagent également skb_copy_header() mais linéarisent toutes les données paginées dans un stockage de tête fraîchement alloué et se retrouvent avec nr_frags == 0, si bien que skb_has_shared_frag() renvoie faux d'elle-même ; ils n'ont pas besoin de modification. La même omission existe dans skb_gro_receive() et skb_gro_receive_list(). Le premier déplace les descripteurs de fragments du skb entrant vers le dernier sous-skb de l'accumulateur via deux chemins (une boucle directe de déplacement de fragments et le chemin head_frag + memcpy) ; le second rattache le skb entrant tout entier à la frag_list de p. En aval, skb_segment() ne lit que skb_shinfo(p)->flags, et skb_segment_list() réutilise le shinfo de chaque sous-skb comme nskb — p et lp doivent tous deux porter le marqueur. La même omission existe également dans tcp_clone_payload(), qui construit un skb de sonde MTU en déplaçant des descripteurs de fragments des skbs de sk_write_queue vers un nskb fraîchement alloué. Ce helper appartient à la même famille et justifie la même correction par souci de cohérence ; aucun code d'écriture en place côté TX TCP n'est actuellement connu pour atteindre une page utilisateur via cette lacune, mais un futur consommateur dépendant du marqueur régresserait silencieusement. La même omission existe dans skb_segment() : la fusion du flag à chaque itération ne prend en compte que le flag de head_skb, et le switch interne qui réattache frag_skb à list_skb lors de l'épuisement des fragments de head_skb n'intègre pas le flag du nouveau frag_skb dans nskb. Repliez le flag de frag_skb aux deux endroits afin que les segments qui prélèvent des fragments des membres de frag_list portent le marqueur.