Sasha Levin, ingénieur chez Nvidia et co-responsable des branches LTS (Long Time Support) et stables du noyau Linux au sein de la Fondation Linux, a proposé la possibilité pour les administrateurs de serveurs de désactiver des fonctions vulnérables en attendant la publication des correctifs. Cette suggestion de kill switch est une mesure d’atténuation quand une faille est découverte. Dans son article, l’ingénieur constate que lorsqu’une vulnérabilité est trouvée, « les parcs de serveurs restent exposés jusqu’à la compilation, la distribution et l’installation d’un noyau corrigé. Pour bon nombre de ces problèmes, la mesure d’atténuation la plus simple consiste à cesser d’appeler la fonction défectueuse ».

Il propose donc la mise en place d’un kill switch pour certains paquets du noyau. « Pour la plupart des utilisateurs, le coût lié à l’arrêt temporaire de fonctions concernées est bien moindre que celui de l’utilisation d’un noyau que l’on sait vulnérable jusqu’au déploiement d’un correctif », constate Sasha Levin. Cette proposition intervient alors que plusieurs failles Linux de gravité élevée ont été récemment découvertes, notamment Copy Fail (CVE-2026-31431) et Dirty Frag, qui aboutissent à des élévations de privilège. L'attaque Dirty Frag combine deux vulnérabilités distinctes affectant le sous-système IPsec Encapsulating Security Payload (ESP) de Linux (CVE-2026-43284) et le protocole réseau RxRPC (CVE-2026-43500).

Une technique contestée

Cette proposition a déclenché un débat houleux parmi les professionnels de la cybersécurité. Par exemple, sur le forum Reddit r/cybersecurity, elle a été qualifiée de « terrible », de « ridicule », d'« absolument terrifiante » et de « tout simplement trop risquée ». « Les gens utiliseront un kill switch au lieu d'appliquer des correctifs », a fait valoir un contributeur. D’autres ont également pointé des failles dans le code proposé. Pour Kellman Meghu, directeur technique de la société canadienne de gestion des incidents DeepCove CyberSecurity « un kill switch, c’est bien en théorie, mais cela n’accélère pas la capacité à se protéger plus rapidement qu’aujourd’hui, étant donné que le contrôle des modifications doit toujours être soigneusement testé et géré ». Selon le dirigeant, le kill switch pose plusieurs problèmes : d’abord, peu d’administrateurs sont en mesure d’évaluer facilement son impact sur les services de leur entreprise. Il faut « s’interroger sur l’impact de la désactivation des fonctions du noyau sur les opérations. Il est nécessaire de tester et valider le kill switch en dehors de l’environnement de production ce qui demande du temps et des efforts », glisse-t-il. En second lieu, il explique que « se contenter d’activer ce procédé en espérant que cela suffise n’est pas une stratégie idéale pour les applications en entreprise ». Et de rappeler que « la faille Copy Fail n’est pas représentative de tous les problèmes auxquels sont confrontés les professionnels de Linux ». Il résume sa pensée en indiquant que le kill switch ressemble « à un pansement qui ne fonctionne que sur certaines blessures ».

Robert Enderle, analyste pour Enderle Group, trouve pour sa part cette technique très classique du type « briser la vitre en cas d’urgence ». Il pense que pour les administrateurs « c’est une réponse très pragmatique au décalage entre la divulgation d’une faille zero-day et le déploiement d’un correctif ». Dans des environnements à haute disponibilité où le redémarrage d’un parc de machines est un cauchemar, la possibilité de désactiver une fonction spécifique et non essentielle (comme un protocole réseau obscur) en cours d’exploitation représente un avantage énorme. « On remplace en quelque sorte une fonctionnalité de niche contre l’intégrité immédiate du système, sans le temps d’arrêt lié à un cycle de correctifs complet » note-t-il. Il reconnait cependant que ce pouvoir pourrait être à double tranchant. « Bien qu’il ne crée pas de nouveau point d’entrée, puisqu’il faut toujours un accès root pour déclencher l’action, il ouvre la porte à un déni de service massif. Il n’y a pas de filet de sécurité : si un administrateur désactive par erreur une fonction critique de gestion de la mémoire, le système est fichu. » Les entreprises pourraient aussi s’en servir pour retarder l’application effective des correctifs. « C’est un outil puissant qui doit rester entre les mains d’équipes de sécurité expérimentées, mais pour l’administrateur système moyen, c’est probablement un outil un peu trop « radical » pour être rassurant », a-t-il estimé. « Compte tenu de la composition actuelle des équipes IT, cela risque d’être bien trop dangereux pour que la plupart envisagent de l’utiliser. » Cependant, Mike McGrath, vice-président Core Platforms chez Red Hat pense que cela peut marcher. « Nous sommes favorables à l'intégration de fonctionnalités de kill switch dans le noyau, d'autant plus que le rythme et la gravité des exploits s'intensifient en raison des analyses menées par les LLM », explique-t-il. Et d’ajouter que « les correctifs restent absolument essentiels pour réparer les vulnérabilités ». Finalement le débat est loin d’être clos.