[!WARNING] Ceci est un outil de stress du noyau. Sur un noyau vulnérable, il élargit délibérément une fenêtre de race use-after-free ; un déclenchement peut faire planter ou corrompre la machine. Ne l'exécutez que sur des machines que vous possédez ou pour lesquelles vous êtes explicitement autorisé à tester (VM de test, machines CI jetables), jamais sur des systèmes de production.

Le bug en une minute

SO_REUSEPORT permet à de nombreux sockets de se lier au même port UDP ; pour chaque paquet entrant, le noyau choisit un socket du groupe dans reuseport_select_sock() (net/core/sock_reuseport.c). Un groupe peut installer un programme sélecteur — un programme BPF classique attaché avec setsockopt(SO_ATTACH_REUSEPORT_CBPF) — qui décide par paquet quel socket du groupe le reçoit. Le programme s'exécute dans la softirq RX (traitement de réception réseau) à l'intérieur d'une section critique de lecture RCU.

Le bug : lorsque le programme est remplacé ou détaché via setsockopt() (reuseport_attach_prog() / reuseport_detach_prog()), l'ancien programme cBPF est libéré immédiatement par sk_reuseport_prog_free(), sans attendre les lecteurs RCU en cours. Un CPU qui parcourt encore les instructions du programme libéré lit de la mémoire vmalloc libérée :

Le chemin sélecteur eBPF (SO_ATTACH_REUSEPORT_EBPF) n'est pas affecté : il libère déjà les programmes via les étapes différées de bpf_prog_put(). Le correctif applique le même traitement au chemin cBPF — une période de grâce RCU avant que l'ancien programme ne soit libéré.

Le rapport KASAN amont (sur un noyau de debug 7.0) :

Contenu de ce dépôt

Démarrage rapide

Sur une machine de test Linux :

Prérequis :

• Une machine de test Linux que vous pouvez faire planter (VM ou bare metal). Un noyau avec KASAN activé est fortement recommandé — sans KASAN, un déclenchement de race peut passer complètement inaperçu.
• gcc et bash.
• Root pour les vérifications du wrapper (dmesg, /proc/vmallocinfo, sysctl) ; le marteau lui-même s'exécute sans privilèges (le repro amont tournait en UID 1000).
• Une machine au repos : le trafic de fond et les autres utilisateurs de BPF ajoutent du bruit à la vérification des fuites.
• Le marteau lie des ports UDP à partir de 21000 (un port par groupe reuseport) — assurez-vous qu'ils sont libres.

Résultats attendus :

• Noyau vulnérable — splat KASAN dans dmesg → RC=2 ; parfois la vérification d'intégrité du marteau se déclenche en premier → RC=4.
• Noyau corrigé — exécution propre, RC=0, compteur vmalloc bpf_prog stable.

La fenêtre de race est minuscule (libération vs. exécution RX en cours), donc considérez une seule exécution propre comme non concluante. Pour un vrai test, exécutez pendant des heures, par exemple :

Le marteau : reuseport_race_hammer

Chaque groupe exécute un thread churner qui échange et détache le sélecteur cBPF via setsockopt() en boucle serrée, et des threads sender qui inondent le groupe de datagrammes UDP de 64 octets pendant que les récepteurs comptent la livraison par socket.

Phases d'exécution (T = dur_sec) :

Vérification d'intégrité : pendant la phase de mesure, le programme final sélectionne de manière déterministe le dernier socket du groupe. Si les paquets reçus par le groupe pendant cette fenêtre n'ont pas tous atterri sur ce socket, la sélection a mal tourné (un effet possible de l'UAF même sans KASAN) → code de sortie 2.

Codes de sortie du marteau : 0 PASS · 1 erreur de configuration/exécution · 2 WARN d'intégrité.

run_hammer.sh — wrapper d'exécution unique

Exécute le marteau et ajoute les vérifications qui rendent une exécution unique significative :

1. capture le nombre d'allocations bpf_prog dans /proc/vmallocinfo ;
2. augmente net.core.optmem_max pour que les programmes cBPF de plusieurs Ko s'attachent proprement ;
3. exécute le marteau ;
4. attend DRAIN (30s par défaut) que les libérations différées RCU/workqueue se terminent ;
5. scanne dmesg pour les nouveaux splats (BUG:, Oops:, WARNING:, RIP:, leaked, stuck) ;
6. compare le compteur vmalloc bpf_prog avant/après (vérification des fuites), et scanne optionnellement kmemleak si /sys/kernel/debug/kmemleak existe.

Codes de sortie : 0 propre · 1 erreur de configuration (y compris échec de configuration du marteau) · 2 splat noyau détecté · 3 fuite bpf_prog possible · 4 WARN d'intégrité du marteau.

livepatch_cycle.sh — test du cycle de vie des livepatches

Le correctif libère l'ancien programme cBPF depuis un callback call_rcu(). Si vous livrez le correctif sous forme de livepatch (kernel live patching — code patché dans un noyau en cours d'exécution), la fonction de callback elle-même réside dans le module de patch : une révocation/déchargement alors que des callbacks sont encore en attente libère le texte du module sous les pieds du callback. Ce script exerce des cycles d'application/révocation pendant que le marteau maintient la fenêtre de race chaude, et surveille /sys/kernel/livepatch/*/transition et dmesg.

Codes de sortie : 0 propre · 1 échec de commande · 2 splat ou transition bloquée · 4 WARN d'intégrité du marteau.

CI

La CI compile le marteau avec deux jeux de flags et exécute shellcheck sur les scripts. Les tests noyau à l'exécution ne sont intentionnellement pas exécutés sur les runners CI partagés : le reproducteur a besoin du contrôle sur la version du noyau du runner (et sur un noyau vulnérable, il pourrait faire planter le runner). Exécutez-les sur de vraies machines de test.

Références

• Enregistrement NVD : https://nvd.nist.gov/vuln/detail/CVE-2026-52910
• Correctif : bpf: Free reuseport cBPF prog after RCU grace period — backports stables : 08264d5bba0b, 18fc650ccd7d, 298db6167f81, 87dfb977bdb6, 90e47dc5c572, c3e3fddda6b5, f8b8f1d4bb76, fec41484e7c2
• Suivi Red Hat : https://bugzilla.redhat.com/show_bug.cgi?id=2490779

Licence

GPL-2.0-only — voir LICENSE.