Contexte technique

Le mécanisme MSG_SPLICE_PAGES permet d’attacher directement des pages mémoire issues d’un pipe à une structure skb (socket buffer).

Dans la pile TCP, après appel à skb_splice_from_iter(), les skb concernés sont marqués avec le flag SKBFL_SHARED_FRAG. Ce marquage garantit que tout traitement ultérieur susceptible de modifier les données effectuera d’abord une copie privée (Copy-On-Write, COW).

Problème identifié

Les chemins de traitement des datagrammes IPv4/IPv6 (UDP) ne positionnaient pas ce flag lors de l’insertion de pages dans des skb.

Conséquence :

1. Un paquet ESP-in-UDP construit à partir de pages issues d’un pipe partagé est considéré comme un skb non linéaire classique non cloné.
2. L’entrée ESP emprunte alors un chemin rapide (fast path) sans mécanisme de Copy-On-Write.
3. Le déchiffrement est effectué en place, sur des données qui ne sont pas exclusivement
   possédées par le skb.

Cela ouvre la voie à des corruptions mémoire et à des scénarios d’exploitation, notamment illustrés par le projet Dirty Fragment.

Correction apportée

Les modifications introduites sont les suivantes :

1. Les fragments de datagrammes IPv4/IPv6 sont désormais marqués avec
   SKBFL_SHARED_FRAG, en cohérence avec le comportement TCP.
2. Le traitement ESP vérifie ce flag et appelle skb_cow_data() lorsque nécessaire.
3. Cela garantit que les données sont copiées avant toute modification, empêchant le déchiffrement sur des fragments partagés.

Impact sur les performances

Les skb non linéaires privés continuent d’utiliser le chemin rapide existant.
L’impact est donc limité aux cas impliquant des fragments partagés.

Comportement côté sortie (ESP output)

La correction n’introduit pas de modification intentionnelle sur le chemin de sortie ESP :

1. Dans esp_output_head(), le chemin optimisé qui ajoute les données ESP dans la zone de fin (tailroom) du skb existant n’est pas applicable aux skb non linéaires.
2. En effet, skb_tailroom() retourne zéro lorsque skb->data_len != 0, alors que la taille des données ESP est strictement positive.
3. Par conséquent, la sortie ESP utilise soit :
   - un chemin de fragmentation dédié,
   - soit un appel à skb_cow_data().

Réferences

https://github.com/0xBlackash/CVE-2026-43284
https://github.com/advisories/GHSA-mmw8-mxmc-8w2r
https://github.com/suominen/CVE-2026-43284
https://github.com/scriptzteam/Paranoid-Dirty-Frag-CVE-2026-43284
https://www.cve.org/CVERecord?id=CVE-2026-43284
https://access.redhat.com/security/cve/cve-2026-43284
https://nvd.nist.gov/vuln/detail/CVE-2026-43284
https://www.microsoft.com/en-us/security/blog/2026/05/08/active-attack-dirty-frag-linux-vulnerability-expands-post-compromise-risk/
https://explore.alas.aws.amazon.com/CVE-2026-43284.html