Le noyau Linux ajoute un flag de taint pour filtrer les rapports de bugs des bots de fuzzing
Le 24 septembre 2026, Greg Kroah-Hartman a intégré à driver-core-next un nouveau flag de taint, TAINT_FORCED_BIND, qui marque les noyaux dont les fichiers sysfs bind/unbind ont été manipulés. Il cible les bots de fuzzing comme syzbot qui lient arbitrairement des pilotes à des périphériques et noient les mainteneurs sous des rapports de bugs sans intérêt.
24 septembre 2026. Greg Kroah-Hartman intègre dans sa branche driver-core-next un nouveau flag de taint baptisé TAINT_FORCED_BIND. 24 septembre 2026. Phoronix documente la motivation : les bots de fuzzing comme syzbot abusent des fichiers bind/unbind de sysfs pour lier n’importe quel pilote à n’importe quel périphérique. 2026. Le patch est attendu dans le cycle Linux 7.4. Pourquoi c’est important : le problème n’est pas technique, il est organisationnel — l’automatisation, censée aider la revue de code, produit désormais assez de bruit pour noyer les mainteneurs et générer des correctifs inutiles de la part de développeurs novices.
Ce que font les fichiers bind/unbind de sysfs
Le sous-système sysfs expose, pour chaque pilote, deux attributs particuliers : bind et unbind. Écrire l’identifiant d’un périphérique dans unbind le détache de son pilote à chaud, sans recompilation ni redémarrage. Écrire le même identifiant dans bind rattache un périphérique arbitraire — désigné par son bus ID — à un pilote donné.
Ces attributs ont été créés, il y a des décennies, pour accélérer le travail des développeurs : tester un nouveau pilote sans recompiler le noyau, réinitialiser un périphérique bloqué, ou passer un périphérique à une machine virtuelle par passthrough. Ce sont des outils de débogage légitimes, pensés pour des mains expertes.
Le problème est que cette même API permet de lier n’importe quoi à n’importe quoi. Rien n’empêche d’écrire l’ID d’une carte réseau dans le bind d’un pilote audio. Le noyau tentera l’opération, échouera plus ou moins proprement — et produira au passage des erreurs qui ressemblent à un vrai bug.
L’« attaque » de fuzzing contre la revue de code
C’est exactement ce que les outils de fuzzing ont découvert. syzbot, le fuzzer du noyau maintenu par Google, a décidé de tester des combinaisons aléatoires de pilotes et de périphériques en utilisant bind/unbind. Le résultat, rapporté par Greg Kroah-Hartman, est un déluge de rapports de bugs pour des associations « impraticables » et « sans aucun rapport avec un cas d’usage réel ».
Le mot qu’il emploie est révélateur : « attack » — attaque. Il écrit que l’API « a récemment subi une attaque de fuzzing majeure via des outils comme syzbot qui tentent de lier aléatoirement n’importe quel pilote à n’importe quel type de périphérique, causant des tonnes d’erreurs inutiles et des correctifs de noyau sans objet générés par des développeurs novices qui ne se méfient pas ».
Le mécanisme est subtil. Le fuzzer génère un rapport d’erreur. Un développeur débutant — souvent un nouveau contributeur cherchant un premier patch — prend le rapport au sérieux, rédige un correctif pour un bug qui n’existe pas dans les conditions réelles. Le mainteneur doit alors revoir et rejeter ce correctif. L’automatisation a ainsi déplacé le coût : elle produit du travail de tri et de rejet au lieu d’en économiser.
Le flag TAINT_FORCED_BIND, un marqueur de signal
La réponse de Greg Kroah-Hartman est élégante parce qu’elle ne supprime pas l’API — elle la marque. Dès qu’un des fichiers bind ou unbind d’un pilote est écrit, le noyau en cours d’exécution se voit attribuer le flag TAINT_FORCED_BIND. Tout rapport de bug émis par ce noyau portera alors la mention du flag, signalant immédiatement au mainteneur que les attributs ont été manipulés et que le scénario ne relève pas d’un flux de travail normal.
Le mécanisme du taint est une brique ancienne et éprouvée du noyau. Il s’agit d’un masque de bits consultable dans /proc/sys/kernel/tainted, où chaque bit correspond à une condition particulière : module propriétaire chargé, module hors-arbre, table ACPI surchargée, noyau patché à chaud, etc. Les outils de diagnostic et les mainteneurs s’en servent déjà pour filtrer les rapports peu fiables. TAINT_FORCED_BIND ajoute une entrée à cette liste.
L’intérêt ne s’arrête pas au tri manuel. Le noyau expose aussi panic_on_taint, un paramètre qui force un kernel panic dès qu’un flag donné est posé. Un environnement de fuzzing peut ainsi configurer panic_on_taint pour s’arrêter net au premier usage de bind/unbind, évitant de poursuivre des combinaisons de test inutiles :
# Lire l'état de taint du noyau en cours
cat /proc/sys/kernel/tainted
# Paniquer dès qu'un flag donné est posé (bitmask ; voir
# Documentation/admin-guide/tainted-kernels.rst pour la valeur exacte)
echo 1 > /proc/sys/kernel/panic_on_taintLa valeur exacte du bit de TAINT_FORCED_BIND sera fixée lors de l’intégration dans le cycle 7.4 ; le principe, lui, est déjà documenté dans la politique des noyaux taintés.
Le vrai sujet : la bande passante des mainteneurs
Derrière ce patch technique se joue un enjeu que nous suivons de près sur ce blog : la saturation des mainteneurs. Le cycle 7.3 avait déjà montré les deux faces de l’automatisation — des correctifs générés par des LLM qui ont aidé à nettoyer des bugs, mais aussi un flux de contributions dont la qualité doit être triée à la main, comme le rappelle l’article sur Linux 7.3-rc4.
TAINT_FORCED_BIND s’inscrit exactement dans cette tension. L’automatisation — qu’il s’agisse de fuzzing ou de génération de code par IA — produit du volume à un rythme que la revue humaine ne peut pas absorber. La réponse des mainteneurs n’est pas de refuser l’automatisation, mais de métadater le bruit : un flag de taint est une façon de dire « ceci a été provoqué par une manipulation hors du flux normal, à trier en conséquence ».
La leçon dépasse le noyau. Toute équipe qui branche un fuzzer ou un générateur de correctifs sur sa base de code finit par affronter le même problème : comment distinguer le signal (un vrai bug) du bruit (une combinaison invalide). La réponse du noyau — marquer la condition plutôt que l’interdire — est directement transposable à un pipeline CI, où l’on tagge les échecs provoqués par des conditions artificielles au lieu de les noyer dans un backlog unique.
Une brique ancienne, un usage nouveau
Le mécanisme du taint n’est pas une invention récente. Le noyau maintient depuis des années un masque de bits documenté dans Documentation/admin-guide/tainted-kernels.rst, où chaque bit signale une condition qui rend un rapport de bug moins fiable : chargement d’un module propriétaire, module hors-arbre, table ACPI surchargée, noyau patché à chaud, verrou logiciel (soft lockup), etc. Les mainteneurs et les outils comme scripts/decode_stacktrace.sh s’appuient sur ce masque pour écarter d’emblée les rapports émanant d’un noyau « pollué ».
TAINT_FORCED_BIND est donc l’application d’une brique ancienne à un problème nouveau : le bruit produit par l’automatisation. C’est aussi un signal à destination des fuzzers eux-mêmes. Un environnement de fuzzing qui s’auto-marque via panic_on_taint cesse de gaspiller des cycles sur des combinaisons sans valeur, et produit des rapports que les mainteneurs peuvent traiter avec la bonne hypothèse — celle d’un scénario provoqué, pas d’un usage réel.
Il reste une question ouverte : celle de la responsabilité des outils de fuzzing. syzbot a démontré une capacité remarquable à découvrir des bugs réels ; le flag ne remet pas cela en cause. Il corrige en revanche un effet de bord — le coût que les rapports sans intérêt font peser sur les mainteneurs et sur les contributeurs débutants. C’est une reconnaissance implicite que l’automatisation, quand elle n’est pas calibrée, peut dégrader le processus qu’elle est censée accélérer.
Verdict
TAINT_FORCED_BIND n’est pas un patch de sécurité : c’est un patch de santé du processus. Il ne corrige aucun bug, mais il réduit le coût du tri que l’automatisation fait peser sur les mainteneurs. Si vous contribuez au noyau ou suivez ses rapports de bugs, retenez la mécanique : un noyau dont bind/unbind a été écrit affichera le flag, et tout rapport qui en émane est à déprioriser. Si vous faites du fuzzing ou de la génération de correctifs en interne, transposez l’idée — marquez vos conditions de test artificielles dans les rapports, et configurez panic_on_taint ou son équivalent pour arrêter net les itérations sans valeur. Le signal, pas le volume, est la seule métrique qui compte quand la revue est faite par des humains.