CVE-2025-68341 in Linux
Résumé
par VulDB • 26/05/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
veth : réduire la section de retour XDP no_direct pour corriger une condition de concurrence (race condition)
Comme expliqué dans le commit fa349e396e48 (« veth : Correction d'une condition de concurrence avec AF_XDP exposant des descripteurs anciens ou non initialisés »), pour veth, il existe un risque qu'après l'appel à `napi_complete_done()`, un autre processeur puisse lancer une autre instance NAPI exécutant `veth_pool()`. Pour NAPI, cela est correctement géré car la vérification `napi_schedule_prep()` empêche la planification de plusieurs instances, mais pour le code restant dans `veth_pool()`, celui-ci peut s'exécuter de manière concurrente avec la nouvelle instance NAPI démarrée.
Le problème/la condition de concurrence réside dans le fait que `xdp_clear_return_frame_no_direct()` n'est pas conçu pour être imbriqué.
Avant le commit 401cb7dae813 (« net : Référence de bpf_redirect_info via task_struct sur PREEMPT_RT. »), le contexte réseau BPF temporaire `bpf_redirect_info` était stocké par processeur, ce qui ne posait pas de problème. Depuis ce commit, le contexte BPF est stocké dans la structure `task_struct` de « current ». Lors de l'exécution de veth en mode NAPI threadé, le kthread devient la zone de stockage. Une condition de concurrence existe désormais entre deux appels concurrents à la fonction `veth_pool()`, l'un sortant de NAPI et l'autre exécutant une nouvelle instance NAPI, tous deux utilisant le même contexte réseau BPF.
La condition de concurrence se produit lorsqu'un autre processeur entre dans la section `xdp_set_return_frame_no_direct()` avant que l'appel à la fonction de nettoyage `xdp_clear_return_frame_no_direct()` ne soit effectué à la sortie de `veth_pool()`.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.