Deux failles noyau Linux exploitées en deux semaines : ce que les équipes SecOps doivent savoir avant le prochain patch Tuesday

La première, CVE-2025-21756, est une élévation de privilèges via une faille use-after-free dans le sous-système vsock du noyau. Score CVSS 7.8. Un attaquant local non privilégié peut obtenir un accès root. Le code d'exploitation circule. La seconde, CVE-2024-53197, touche le pilote audio USB ALSA — un composant que personne n'associe spontanément à un vecteur d'attaque critique. Elle a pourtant été utilisée dans une chaîne d'exploitation réelle documentée contre un activiste serbe, combinée avec deux autres vulnérabilités, selon des travaux publiés par Amnesty International en début d'année.

C'est Microsoft Threat Intelligence Center qui a signalé CVE-2024-53197 au mainteneur du noyau Linux. L'entreprise l'a ensuite intégrée dans son propre Patch Tuesday d'avril 2025, pour ses distributions Linux embarquées dans Azure et WSL. Quand Microsoft patche le noyau Linux avant certaines distributions majeures, la question de la réactivité des éditeurs traditionnels se pose mécaniquement.

vsock

CVE-2025-21756 est plus classique dans sa mécanique, plus dangereuse dans son rayon d'action. Le sous-système vsock gère les communications entre machines virtuelles et hôtes. Il est actif par défaut sur la quasi-totalité des hyperviseurs KVM et sur les instances cloud qui utilisent des sockets VM. Un use-after-free dans ce composant donne accès au noyau de l'hôte depuis une VM guest — le scénario que tout RSSI en environnement mutualisé redoute.

Le PoC public exploite un défaut dans la gestion du compteur de références lors du transport vsock. La fonction virtio_transport_destruct déréférence un pointeur déjà libéré. Le correctif upstream est disponible depuis le 12 mars dans la branche mainline. Red Hat a publié un advisory le 27 mars. Canonical a suivi le 2 avril. SUSE le 4 avril. Pour les noyaux personnalisés compilés en interne — fréquents dans les environnements télécom et edge — il n'y a pas de véhicule de distribution automatique.

ALSA, Cellebrite, Belgrade

CVE-2024-53197 a une histoire plus inhabituelle. La faille dans le pilote audio USB a été identifiée comme faisant partie d'une chaîne d'exploitation vendue par Cellebrite, utilisée par les services de sécurité serbes pour déverrouiller le téléphone Android d'un journaliste. Google a patché Android en avril. Le noyau Linux upstream a intégré le correctif en décembre 2024. Mais la propagation vers les distributions serveur a pris des semaines supplémentaires, parce que le composant ALSA USB est rarement priorisé dans les cycles de mise à jour des noyaux LTS orientés datacenter.

Un pilote audio. Sur un serveur. Le composant est compilé dans le noyau par défaut sur la majorité des distributions génériques. Il n'est pas chargé dynamiquement — il est là, dans le binaire, même si aucun périphérique audio USB n'est branché. La surface d'attaque n'est pas théorique : un dispositif USB malveillant connecté physiquement ou passé via USB/IP suffit.

Trois distributions, trois calendriers

Pour CVE-2024-53197, le décalage entre le correctif upstream et la disponibilité sur RHEL dépasse trois mois. Red Hat a classé la faille en sévérité Important le 8 avril, après que la CISA l'a ajoutée à son catalogue KEV le 4 avril. Avant cette date, la CVE existait dans les bases publiques sans advisory Red Hat associé.

Les équipes qui utilisent des scanners de vulnérabilité configurés sur les flux advisory des distributions — et non sur le NVD ou les KEV — n'ont pas vu cette faille pendant treize semaines.

Le vrai problème opérationnel

Patcher un noyau Linux en production exige un redémarrage. Ou un mécanisme de live patching — kpatch chez Red Hat, Livepatch chez Canonical, kGraft chez SUSE. Ces outils couvrent un sous-ensemble de CVE. CVE-2025-21756, qui touche une structure de données dans le transport vsock, est éligible au live patching sur RHEL 9 depuis le 3 avril. Sur Ubuntu, le live patch n'était pas encore disponible au 10 avril pour cette CVE spécifique.

Pour les environnements conteneurisés, le noyau est celui de l'hôte. Kubernetes ne change rien ici. Un cluster de 200 nœuds avec un noyau vulnérable, c'est 200 machines à redémarrer. Les opérateurs de plateformes managées — OVHcloud, Scaleway, les hyperscalers — ont patché leurs flottes mutualisées entre le 28 mars et le 9 avril selon les cas. Pour le bare metal dédié, le client est seul.

Un responsable infrastructure d'un hébergeur français interrogé en marge du FIC 2025, la semaine dernière à Lille, résumait la situation : « On a trois fenêtres de maintenance par mois pour les noyaux. Quand deux CVE critiques tombent en deux semaines avec exploitation active, on sort du cadre. On patche à chaud ce qu'on peut, on priorise les nœuds exposés, et on espère que le troisième zéro-day n'arrive pas avant vendredi. »

Ce que Microsoft voit

Microsoft a remonté les deux failles. L'entreprise opère plus de 600 000 nœuds Linux dans Azure, selon ses propres déclarations lors de Build 2024. Elle maintient CBL-Mariner (désormais Azure Linux), sa propre distribution interne, et contribue activement au noyau — plus de 3 000 commits en 2024 sur les branches mainline et stable. Sa visibilité sur les exploits Linux en circulation est au moins égale à celle de Red Hat.

Quand Defender for Endpoint sous Linux détecte une exploitation active et que le rapport remonte via MSTIC plutôt que par les canaux habituels du CERT communautaire, cela signifie que la télémétrie de Microsoft sur les workloads Linux dépasse celle de la plupart des SOC internes. C'est un avantage concurrentiel déguisé en contribution open source.

En février 2023, Microsoft avait déjà signalé CVE-2023-20593 (Zenbleed, AMD) via le même canal. Le schéma se répète.

La CISA, le KEV, et le compte à rebours

Les deux CVE figurent désormais dans le catalogue KEV (Known Exploited Vulnerabilities) de la CISA. Pour les agences fédérales américaines, cela impose un correctif sous 21 jours. En Europe, aucun mécanisme contraignant équivalent n'existe. La directive NIS2, transposée en France depuis octobre 2024, exige des « mesures techniques appropriées » sans délai chiffré. Les DSI du périmètre NIS2 qui n'ont pas de politique de patching noyau documentée avec des SLA explicites sont en zone grise réglementaire.

L'ANSSI n'a pas publié d'alerte spécifique sur ces deux CVE au 14 avril. Le CERT-FR a relayé les advisories des distributions sans élévation de priorité.

La salle café du FIC sentait le tabac froid et le stress des astreintes. Un RSSI d'un opérateur d'importance vitale feuilletait un tableau Excel imprimé — sa matrice de priorisation des CVE noyau — en attendant son TGV pour Paris.

Ce qui manque

Aucun éditeur de distribution n'a publié de données sur le taux d'application effectif des correctifs pour ces deux CVE. Red Hat dispose de cette télémétrie via Red Hat Insights. Canonical via Landscape. Ces chiffres ne sont jamais partagés, alors qu'ils permettraient de mesurer la fenêtre d'exposition réelle du parc installé.

On ne sait pas non plus combien d'images conteneur officielles sur Docker Hub, Quay.io ou les registries cloud intègrent déjà un noyau hôte compatible avec les correctifs. Les scans Trivy et Grype évaluent les paquets userland, pas le noyau sous-jacent. L'angle mort est structurel.

Pour les DSI qui veulent une action immédiate : vérifier la version du noyau en production, croiser avec les advisories de la distribution utilisée, activer le live patching si disponible, et — pour vsock — désactiver le module sur les machines qui n'en ont pas besoin. La commande tient en une ligne. Le change management pour l'exécuter en production prend deux jours dans le meilleur des cas.