Cyber Resilience Act et Linux embarqué : CVE-2026-53362

Tous les articles consacrés à CVE-2026-53362 donnent la même mitigation : désactiver les espaces de noms utilisateur non privilégiés. Elle ne fait rien pour votre produit, car un appareil Linux embarqué n'exécute aucun conteneur et la faille reste atteignable depuis tout processus local disposant d'une socket UDPv6. Cet écart entre le conseil entreprise et la réalité embarquée devient un problème juridique le 11 septembre 2026, avec le Cyber Resilience Act.

Dans cet article

• Ce qu'est réellement CVE-2026-53362
• Pourquoi la mitigation publiée ne fait rien sur Linux embarqué
• Quelles versions du noyau sont affectées
• Ce que le Cyber Resilience Act exige dès le 11 septembre 2026
• Comment savoir quel noyau tourne dans votre produit
• Ce que cela change pour votre SBOM et votre politique de divulgation
• Matrice de décision : corriger, backporter, atténuer ou accepter
• En résumé

Ce qu'est réellement CVE-2026-53362

CVE-2026-53362 est une écriture hors limites dans la pile IPv6 du noyau Linux, notée 7.8 par la National Vulnerability Database (NVD). Elle porte le vecteur AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, relève des classes CWE-787 et CWE-122, et a rejoint le catalogue CISA des failles exploitées le 27 août 2026.

Le défaut se situe dans __ip6_append_data(). Sur la branche d'allocation paginée, empruntée sous MSG_MORE, NETIF_F_SG ou avec une taille de fragment importante, le noyau calcule alloclen = fragheaderlen + transhdrlen et pagedlen = datalen - transhdrlen. Or datalen contient déjà fraggap, les octets reportés depuis le tampon précédent. La zone linéaire se retrouve sous-dimensionnée d'exactement fraggap octets tandis que pagedlen est surévalué d'autant, et la copie déborde donc au-delà de skb->end dans la structure skb_shared_info.

Comment un processus non privilégié atteint la faille

Un utilisateur non privilégié y accède via une socket UDPv6 combinant MSG_MORE et MSG_SPLICE_PAGES. Ni root, ni capability, ni matériel particulier. La fragmentation IPv6 elle-même est spécifiée par le RFC 8200, et le protocole n'est pas en cause : il s'agit d'une erreur arithmétique dans une implémentation.

L'historique compte pour qui audite un arbre ancien. Selon les mainteneurs du noyau Linux, le mauvais calcul est arrivé avec le commit 773ba4fe9104, mais c'est un second changement, ce650a166335, qui l'a rendu atteignable. Avant lui, la longueur de copie négative renvoyait simplement -EINVAL. Après lui, le même chemin a pu se poursuivre, et une requête rejetée est devenue une corruption mémoire. Un arbre portant le premier commit mais pas le second est affecté sur le papier et bien plus difficile à exploiter en pratique.

Pourquoi la mitigation publiée ne fait rien sur Linux embarqué

La mitigation publiée est un réglage sysctl qui bloque les espaces de noms utilisateur non privilégiés, ce qui ferme la voie d'évasion de conteneur mais laisse le défaut du noyau totalement intact. Sur un produit qui ne crée jamais de conteneur, elle protège une fonction que l'appareil n'utilise pas.

Le raisonnement de l'avis est juste pour son propre public. Selon Red Hat, dont le bulletin nomme le problème ipv6_frag_escape, un attaquant présent dans un conteneur crée un espace de noms réseau, déclenche le débordement, s'échappe vers l'hôte, contourne SELinux et obtient root. Retirez la création de namespaces et cette chaîne casse. Les parcs d'entreprise exécutent des conteneurs, la consigne gagne donc du temps chez eux, et l'avertissement associé sur la rupture de Podman rootless indique clairement pour qui elle a été écrite.

Le modèle de menace sur un appareil sans conteneur

Votre passerelle n'exécute pas Podman rootless. Elle fait tourner quelques démons sous des comptes de service non root, et chacun peut ouvrir une socket UDPv6. Compromettez une interface web, un pont MQTT ou un démon de bus de terrain, et le même débordement se trouve à une séquence d'appels système de la mémoire noyau. Contrairement à l'idée reçue selon laquelle un appareil sans conteneur serait hors périmètre, retirer les namespaces ne retire rien ici.

C'est là que la recopie dérape. Un avis écrit pour un modèle de déploiement est republié comme une consigne universelle, un fabricant le lit, applique le sysctl et note l'exposition comme close. Elle ne l'est pas. Le même schéma a façonné la couverture de l'élévation de privilèges noyau Copy Fail et son évasion Docker. Partir de votre propre architecture plutôt que de celle d'un autre est l'habitude qui l'évite, et c'est la discipline que nous décrivons dans sécuriser un produit IoT du matériel jusqu'au terrain.

Quelles versions du noyau sont affectées

Les versions affectées sont les branches stables à partir de 6.0, chacune vulnérable jusqu'à une version corrective précise. Toute branche située sous sa version corrective contient la faille, et la frontière est nette plutôt que progressive.

Cette liste compte davantage qu'il n'y paraît, car deux de ces branches sont les noyaux long terme sur lesquels les fondeurs figent leur Board Support Package (BSP). Un produit bâti autour d'un i.MX, d'un STM32MP, d'un AM62 ou d'une pièce comparable tourne très souvent en 6.1 ou 6.6, précisément là où vit le défaut. Le choix entre ces branches à la conception est traité dans notre guide sur le choix d'une distribution Linux embarqué selon cinq critères, et le même arbitrage structure le comparatif entre Zephyr, FreeRTOS et Linux temps réel.

Lisez la colonne centrale comme une frontière stricte. Un noyau qui annonce 6.1.176 est vulnérable, 6.1.177 ne l'est pas, et il n'existe aucun état intermédiaire. Les six commits stables porteurs du correctif sont publiés sur git.kernel.org, un par branche maintenue.

Deux pièges pratiques en découlent. Un BSP fournisseur affiche souvent une version commerciale qui ne correspond pas à la base amont, si bien qu'une carte annoncée en "noyau 6.6" peut se situer n'importe où dans cette branche. Et une gamme de produits ancienne embarque fréquemment plusieurs noyaux selon ses révisions, ce qui rend une réponse unique le plus souvent fausse à l'échelle du parc.

Ce que le Cyber Resilience Act exige dès le 11 septembre 2026

Le Cyber Resilience Act (CRA) est le règlement européen, formellement le règlement (UE) 2024/2847, qui rend la notification des vulnérabilités obligatoire pour tout produit comportant des éléments numériques vendu dans l'Union. Ses obligations de notification deviennent contraignantes le 11 septembre 2026.

À partir de cette date, un fabricant doit déposer une alerte précoce sous 24 heures après avoir appris qu'une vulnérabilité de son produit est activement exploitée, puis une notification complète sous 72 heures. Les incidents graves suivent le même schéma en deux temps. Les dépôts passent par la plateforme de signalement unique, qui route vers le CSIRT national et vers l'ENISA plutôt que vers chaque État membre séparément.

CVE-2026-53362 est le cas d'école. Selon CISA, qui l'a ajoutée au catalogue des vulnérabilités activement exploitées le 27 août 2026, la faille est exploitée dans la nature, et c'est exactement la condition que nomme le règlement. Un fabricant livrant encore un noyau 6.1 ou 6.6 non corrigé après le 11 septembre détient une vulnérabilité à notifier, et non une simple dette technique.

Le piège de l'antériorité à l'article 69(3)

Le piège tient à l'article 69(3). Les produits mis sur le marché avant le 11 décembre 2027 échappent aux exigences techniques complètes sauf modification substantielle, et c'est la partie que la plupart des fabricants retiennent. Cette dérogation ne s'étend pas à l'article 14 : les obligations de notification s'appliquent à tous les produits concernés déjà sur le marché. L'antériorité protège votre dossier technique, pas votre devoir de notification. Notre guide complet de conformité au Cyber Resilience Act pour l'IoT et l'embarqué déroule tout le calendrier, où les sanctions atteignent 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial.

Comment savoir quel noyau tourne dans votre produit

La provenance du noyau est la chaîne qui relie un binaire en fonctionnement à l'arbre source et au tag fournisseur qui l'ont produit. Répondre à la question du CRA commence là, car un fabricant incapable de nommer la version présente sur le terrain ne peut pas dire si une vulnérabilité à notifier existe.

La plupart des équipes savent répondre pour le build courant et pas pour le parc, et ces deux réponses divergent vite une fois le produit passé par plusieurs révisions. Notre procédure de test sur un produit existant tient en quatre étapes. Nous lisons /proc/version et la bannière du bootloader sur une unité réelle plutôt que de faire confiance au manifeste de build. Nous localisons la recette du noyau dans la couche Yocto ou la configuration Buildroot et identifions le tag fournisseur qu'elle fige. Nous comparons ce tag à la branche stable amont pour mesurer le retard. Enfin, nous vérifions si les commits stables porteurs du correctif s'appliquent proprement.

Où se situe réellement le risque de planning

Cette dernière étape concentre le risque de planning. Un cherry-pick propre représente une après-midi de travail. Un cherry-pick en conflit sur un arbre fournisseur fortement patché représente un cycle de requalification, raison pour laquelle nous le traitons avec la même rigueur que tout autre risque de projet électronique à anticiper plutôt qu'à découvrir.

Garder cette réponse disponible sur la durée de vie d'un produit relève du système de build, pas de la documentation. Une chaîne reproductible comme celle décrite dans notre article sur le DevOps embarqué, la CI/CD et les tests automatisés transforme une requête noyau à l'échelle du parc en quelques minutes de travail, et la discipline de versionnement traitée dans Git pour les projets électroniques permet de prouver quelle source a produit quel binaire face à un régulateur.

Ce que cela change pour votre SBOM et votre politique de divulgation

Un SBOM est un inventaire lisible par machine qui rend une question de ce type traitable en heures plutôt qu'en semaines. Sous le CRA, il cesse d'être une bonne pratique et devient l'artefact qui détermine si vous pouvez tenir un délai de 24 heures.

Le noyau est le composant le plus difficile à suivre correctement, car il est rarement une dépendance versionnée comme l'est une bibliothèque utilisateur. Il arrive sous forme de tag fournisseur, se fait patcher localement, puis apparaît dans le SBOM comme une ligne unique dont la chaîne de version peut ne correspondre à rien en amont. Un SBOM qui note "linux 6.6" sans le tag fournisseur ni le jeu de patchs ne peut pas dire si 6.6.144 est présent, la seule question qui compte ici.

Les normes de divulgation qui s'appliquent déjà

Le côté réception demande la même préparation. La divulgation coordonnée est normalisée par ISO/IEC 29147 pour la divulgation et ISO/IEC 30111 pour le traitement interne, et un point de contact lisible par machine est défini par le RFC 9116. Les produits industriels portent une obligation parallèle au titre de IEC 62443, et les équipements radio font déjà face à des exigences de cybersécurité via EN 18031 sous la directive RED. Aucune ne remplace le CRA, mais un fabricant qui les a mises en oeuvre est déjà proche de l'état de préparation exigé par l'article 14.

Malgré ce cadrage documentaire, l'artefact décisif est opérationnel : un chemin répété allant de "nous avons appris l'existence d'une CVE" à "nous avons déposé une notification". Les équipes qui n'ont jamais parcouru ce chemin en découvrent les trous sous une horloge de 24 heures, au pire moment possible.

Matrice de décision : corriger, backporter, atténuer ou accepter

Une décision de remédiation est un choix entre quatre réponses, et sous le CRA deux seulement suppriment réellement la vulnérabilité. Le règlement n'impose pas un remède particulier, mais il exige que le choix soit délibéré, documenté et notifié plutôt que laissé implicite.

Faire passer tout le BSP sur une version corrective est la réponse la plus propre quand le fournisseur en a publié une. Backporter les commits convient à un arbre figé qui ne peut pas absorber un changement de branche avant un jalon de certification. Les mesures compensatoires, comme retirer IPv6 là où le produit n'en a pas besoin, gagnent du temps sans supprimer le défaut. Accepter le risque n'est légitime que consigné, justifié et notifié.

Pourquoi désactiver IPv6 est rarement possible

Malgré la tentation de traiter la troisième option comme un correctif, désactiver IPv6 est rarement possible sur un produit connecté moderne. Thread et Matter sont nativement IPv6, et plusieurs opérateurs NB-IoT et LTE-M exploitent des coeurs IPv6 uniquement, comme le détaillent notre comparatif NB-IoT, LTE-M et connectivité satellite et notre comparaison des réseaux LPWAN. Même là où la pile peut être désactivée, le faire sur un parc déployé constitue une mise à jour terrain avec son propre coût de qualification.

Retour terrain : la mise à jour qui ne visait aucune CVE

Une mise à jour de noyau de routine est la forme la moins coûteuse de réponse aux vulnérabilités, car elle supprime des failles dont vous n'avez pas encore entendu parler. Sur un projet récent, dans notre bureau d'études AESTECHNO à Montpellier, nous avons fait passer un client de 6.6 à la LTS 6.18 actuelle au sein de son BSP fournisseur, et la migration a pris quelques jours.

Rien dans ce chantier n'était motivé par une CVE. L'objectif était la maintenance : empêcher l'arbre de dériver davantage par rapport à l'amont tant que le produit restait simple à requalifier. Nous l'avions planifié comme une ligne de maintenance permanente et non comme une réponse à quoi que ce soit, ce qui explique qu'il n'ait suscité ni urgence ni débat sur la criticité.

Nous avons appris ensuite que le noyau 6.6 que nous venions de remplacer portait une CVE de criticité haute. Personne ne l'avait signalée au moment de la migration, et le client n'a jamais eu à trancher à son sujet, car le correctif était déjà livré au titre de la maintenance ordinaire.

Pourquoi la mise à niveau régulière bat le score de criticité

Contrairement à l'idée reçue selon laquelle les mises à jour de noyau devraient être planifiées selon le score de criticité, la mise à jour qui a protégé ce produit est celle que personne n'aurait pu justifier avec un chiffre CVSS. Aucun score ne nous était présenté. Le correctif piloté par la criticité ne couvre jamais que les failles déjà publiées, un sous-ensemble strict de celles réellement présentes dans l'arbre.

Une mise en garde tirée du même projet : passer sur une branche LTS plus récente ne constitue pas en soi un correctif pour une CVE donnée. CVE-2026-53362 affecte 6.18 sous 6.18.38 exactement comme elle affecte 6.6 sous 6.6.144. La fraîcheur de branche apporte un arbre maintenu et une file de backports plus courte, mais c'est la version corrective qui supprime un défaut précis.

Malgré le coût de requalification, nous recommandons de traiter la mise à niveau du noyau comme une ligne de maintenance permanente plutôt que comme une réponse à incident. Quelques jours de travail planifié, au moment que vous choisissez et avec des moyens de test réservés, n'ont rien à voir avec la même migration menée sous l'horloge de l'article 14.

En résumé

CVE-2026-53362 est un défaut présent dans les noyaux long terme que livrent précisément les produits embarqués, exploité dans la nature, avec une mitigation publiée écrite pour un modèle de déploiement que votre appareil n'utilise pas. Cinq points décident de votre exposition.

• Vérifiez la version, pas l'avis. Corrigée en 6.1.177, 6.6.144, 6.12.95, 6.18.38 et 7.1.3. Sous ces numéros le produit est vulnérable, sans état intermédiaire.
• Désactiver les namespaces ne protège rien ici. Sans conteneur sur l'appareil, la voie UDPv6 reste ouverte à tout compte de service local déjà accordé à un démon.
• Votre noyau vient d'un BSP, pas d'une distribution. Personne ne vous poussera ce correctif : le backport et sa requalification vous incombent.
• Le 11 septembre 2026 en fait une obligation sous 24 heures. Une vulnérabilité activement exploitée dans un produit à éléments numériques est exactement le cas déclencheur de l'article 14.
• L'antériorité ne couvre pas la notification. L'article 69(3) exempte les produits anciens des exigences techniques, jamais de l'article 14.

Questions fréquentes

Quelles versions du noyau corrigent CVE-2026-53362 ?

Le correctif a atterri en 6.1.177, 6.6.144, 6.12.95, 6.18.38 et 7.1.3. Tout ce qui va de 6.0 jusqu'à la version corrective de sa branche, exclue, est affecté. La frontière est nette : 6.1.176 est vulnérable et 6.1.177 ne l'est pas. Vérifiez le noyau en fonctionnement avec uname -r sur une unité réelle plutôt que dans le manifeste de build, car un parc passé par plusieurs révisions embarque souvent plus d'une version.

Désactiver les namespaces protège-t-il un appareil embarqué ?

Non. Le réglage user.max_user_namespaces=0 bloque la chaîne d'évasion de conteneur documentée par Red Hat, raison pour laquelle l'avis la recommande aux parcs d'entreprise. Un produit embarqué qui ne crée jamais de conteneur n'en tire rien, car le code vulnérable dans __ip6_append_data() s'atteint par une socket UDPv6 ordinaire. Tout compte de service compromis sur l'appareil peut encore déclencher le débordement : les seuls remèdes réels sont la mise à jour du noyau ou le backport du correctif.

Mon produit relève-t-il de l'article 14 du CRA ?

S'il s'agit d'un produit à éléments numériques mis à disposition sur le marché européen, oui, y compris les unités vendues avant l'application complète du règlement. L'article 69(3) exempte les produits mis sur le marché avant le 11 décembre 2027 des exigences techniques sauf modification substantielle, mais il ne les exempte explicitement pas de l'article 14. Un appareil vendu en 2024 et toujours supporté porte le même devoir de notification qu'un produit livré l'an prochain.

Sous quel délai notifier une vulnérabilité exploitée ?

Une alerte précoce est due sous 24 heures après avoir eu connaissance qu'une vulnérabilité de votre produit est activement exploitée, suivie d'une notification plus complète sous 72 heures décrivant les mesures correctives ou d'atténuation. Les incidents graves suivent le même schéma en deux temps. Les notifications passent par la plateforme de signalement unique, qui route vers votre CSIRT national et vers l'ENISA, un dépôt unique remplaçant les soumissions parallèles dans chaque État membre.

Peut-on désactiver IPv6 au lieu de corriger ?

Parfois, mais bien plus rarement que les fabricants ne l'imaginent. Thread et Matter sont nativement IPv6, un appareil de bâtiment intelligent ou grand public ne peut donc pas s'en passer. Plusieurs opérateurs NB-IoT et LTE-M exploitent des coeurs IPv6 uniquement. Là où IPv6 est réellement inutilisé, le retirer constitue une mesure compensatoire légitime qui réduit l'exposition, mais cela ne retire pas le défaut de l'image ni la vulnérabilité de vos obligations de notification.

Qui backporte le correctif dans un BSP fournisseur ?

En pratique, celui à qui appartient le produit. Les fondeurs publient leurs versions de BSP à leur propre rythme, et un tag figé pour une campagne de certification ne reçoit pas automatiquement les mises à jour de branche stable. Il revient donc au fabricant, ou à son partenaire de conception, de reprendre les commits, de résoudre les conflits avec les patchs locaux et de requalifier l'image. Budgéter ce travail à l'avance coûte bien moins cher que de découvrir le conflit pendant une fenêtre de 24 heures.

Un SBOM suffit-il à satisfaire l'article 14 ?

Non. Une nomenclature logicielle dit ce que contient le produit, ce qui est un prérequis, mais l'article 14 porte sur la notification et non sur l'inventaire. Il faut aussi une veille reliant une CVE publiée à vos propres composants, une politique de divulgation dans l'esprit de ISO/IEC 29147, ainsi qu'une chaîne de réception et d'escalade capable de produire un dépôt en moins de 24 heures. Le SBOM rend cela possible, il ne le rend pas automatique.

Écrit par Hugues Orgitello, fondateur d'AESTECHNO, bureau d'études électronique à Montpellier spécialisé en logiciel embarqué industriel, conception électronique IoT et certification CE/RED des produits connectés. Le détail technique de cette CVE est publié par le NVD et son statut d'exploitation par CISA.

À lire également

• Cyber Resilience Act 2026 : guide complet de conformité IoT et embarqué
• Distribution Linux embarqué : cinq critères pour bien choisir
• Zephyr, FreeRTOS ou Linux temps réel : quel RTOS choisir
• Cybersécurité IoT industriel : menaces et solutions low-cost
• Sécuriser votre produit IoT : du hardware au terrain
• CVE-2026-31431 Copy Fail : LPE kernel et évasion Docker
• SoC, SoM, SBC ou custom : choisir sans se tromper en 2026
• Du prototype à la série : industrialisation sans surprise
• Tests et validation d'un produit électronique
• Due diligence technique hardware : le guide de l'investisseur
• Bureau d'études électronique : conception carte
• Accélérer le time-to-market des produits connectés