La réutilisation des cibles de branche transforme du code JIT libéré en primitive de fuite de données Spectre

Des chercheurs ont révélé Branch Target Reuse, ou BTR, une variante de Spectre v2 qui exploite les prédictions de branche laissées en mémoire après la suppression de code compilé à la volée.

L’équipe de VUSec, à la Vrije Universiteit Amsterdam, et de la Scuola Superiore Sant’Anna a démontré cette technique contre le noyau Linux. Son exploit s’appuyait sur des programmes classic BPF non privilégiés pour extraire le hachage du mot de passe root d’un processus su en cours d’exécution.

L’attaque a permis de récupérer huit octets par seconde. La récupération complète a pris en moyenne trois minutes sur un processeur Intel Raptor Cove et cinq minutes sur un Intel Lion Cove, selon des travaux de recherche présentés le 29 septembre 2026.

Le comportement sous-jacent du processeur a été confirmé sur tous les processeurs testés, chez Intel, AMD et Arm. L’exploitabilité concrète varie toutefois selon l’environnement logiciel, la génération du processeur et les mesures d’atténuation activées.

Les prédictions obsolètes persistent après le recyclage de la mémoire JIT

Les processeurs modernes prédisent la destination des branches indirectes afin de poursuivre l’exécution des instructions sans attendre que la cible correcte soit déterminée. Les attaques de type Spectre manipulent ou exploitent ce comportement spéculatif pour accéder à des informations que l’exécution architecturale ne devrait pas exposer.

BTR s’intéresse à ce qui se produit lorsque la mémoire exécutable du JIT est recyclée.

Un moteur JIT peut compiler un programme, placer son code machine à une adresse donnée, puis libérer ce code. La même zone mémoire peut alors accueillir un autre programme. Même si son contenu a changé, le processeur peut conserver des informations sur les cibles de branche associées au code précédent.

Une branche indirecte peut alors spéculer vers le code de remplacement en utilisant une cible obsolète. Celle-ci peut pointer vers un emplacement inattendu ou mal aligné dans la nouvelle séquence d’instructions.

L’exécution architecturale finit par rejeter le chemin incorrect. Mais, avant cela, des instructions spéculatives peuvent accéder à des données sensibles et modifier le cache. Un attaquant peut mesurer ces effets sur le cache et déduire les données octet par octet.

Les chercheurs décrivent ce mécanisme comme une primitive spéculative d’utilisation après libération (« speculative execute-after-free ») : le processeur se comporte comme si une ancienne relation de flux de contrôle était toujours valide, alors que le code correspondant n’existe plus.

Un exploit Linux récupère le hachage d’un mot de passe root

La démonstration sur Linux reposait sur des programmes classic BPF non privilégiés, ou cBPF. Les chercheurs ont entraîné un prédicteur de branche à l’aide d’un programme, l’ont libéré, puis ont fait en sorte qu’un autre code compilé par JIT occupe la même zone mémoire.

Ils ont ensuite ciblé un processus su en cours d’exécution et extrait de sa mémoire le hachage du mot de passe root. Selon les comptes rendus de cette recherche, dans le scénario testé, l’exploit pouvait lire n’importe quelle zone de mémoire sur les processeurs Intel récents, y compris sur des systèmes entièrement à jour utilisant les paramètres de sécurité par défaut.

L’équipe a mis au point deux exploits cBPF de bout en bout. Le premier fonctionnait avec la configuration par défaut. Le second visait les systèmes où l’obfuscation des constantes BPF était activée, une mesure destinée à empêcher l’apparition directe de constantes contrôlées par un attaquant dans le code généré.

Pour cette seconde version, les chercheurs ont encodé les instructions contrôlées par l’attaquant dans les décalages de saut. Ils sont tout de même parvenus à récupérer le hachage du mot de passe en cinq minutes.

La récupération d’un hachage ne revient pas à obtenir le mot de passe en clair. L’attaquant devrait casser le hachage séparément, éventuellement à l’aide de ressources de calcul locales ou dans le cloud. La réussite de cette opération dépend de la robustesse du mot de passe et de l’algorithme de hachage utilisé.

La méthode démontrée suppose également que l’attaquant puisse exécuter des programmes cBPF non privilégiés. Dans l’environnement décrit par les chercheurs, les fonctionnalités plus avancées du JIT eBPF nécessitent des privilèges. Le cBPF reste toutefois utilisé pour seccomp, le filtrage des sockets et le filtrage des paquets. Docker et Chrome font partie des applications qui s’appuient sur ces mécanismes.

Les plages de versions concernées du noyau Linux n’ont pas été divulguées. Les administrateurs ne peuvent donc pas déterminer s’ils sont exposés en comparant simplement leur noyau à une liste publiée de versions vulnérables.

Deux CVE couvrent la réutilisation du JIT BPF et la purge des prédicteurs

Les correctifs Linux sont associés à CVE-2026-64507 et CVE-2026-64508. Les informations NVD fournies ne mentionnent ni score CVSS, ni vecteur, ni classification CWE, ni plage de versions concernées.

CVE-2026-64507 concerne le renforcement appliqué lorsque les mesures d’atténuation de Spectre v2 sont actives. Le noyau déclenche une barrière de prédiction de branche indirecte (IBPB) lors de la réutilisation de mémoire du JIT BPF, afin d’empêcher les prédictions obsolètes de se reporter sur du code nouvellement écrit.

L’implémentation décrite ne déclenche pas cette purge lorsque le répartiteur BPF utilise déjà une séquence retpoline. La modification ne s’applique que lorsque le JIT BPF est actif et est conditionnée par CONFIG_BPF_JIT, ce qui permet aux noyaux compilés avec CONFIG_BPF_JIT=n de fonctionner correctement.

CVE-2026-64508 porte sur la gestion de la mémoire exécutable par l’allocateur du JIT BPF. Celui-ci regroupe de petits programmes dans des allocations plus vastes et recycle l’espace au fur et à mesure que les programmes sont chargés et supprimés. Une prédiction créée pour un ancien programme peut donc diriger l’exécution spéculative vers du nouveau code placé à la même adresse.

Le renforcement associé purge les prédicteurs de branche indirecte avant la réutilisation de cette mémoire JIT. Selon les informations rapportées, les développeurs Linux ont implémenté une mesure d’atténuation pour x86 qui déclenche une IBPB sur chaque cœur du processeur lorsqu’un code cBPF est placé dans une zone précédemment occupée par du code BPF.

Les correctifs ont été intégrés au noyau Linux, mais les numéros exacts des versions corrigées ne sont pas connus. D’après les données disponibles, aucune des deux CVE n’a de statut confirmé dans le catalogue des vulnérabilités exploitées de la CISA (Known Exploited Vulnerabilities), ni de date limite de correction. Il ne faut donc pas présenter l’exploit de recherche comme une attaque confirmée dans la nature.

Firefox et GraalVM présentent d’autres surfaces d’attaque

BTR ne se limite pas au JIT BPF de Linux. Les chercheurs ont également observé des comportements pertinents dans le moteur SpiderMonkey de Firefox et dans Oracle GraalVM, sans toutefois parvenir à produire un exploit complet de bout en bout dans ces deux cas.

Dans SpiderMonkey, les prédictions obsolètes ont persisté après la réutilisation d’adresses de code JIT sur des processeurs Intel. Les chercheurs estiment qu’une technique aboutie pourrait permettre de fuir plusieurs dizaines d’octets par seconde, mais des travaux supplémentaires seraient nécessaires pour transformer la preuve de concept en une attaque fonctionnelle contre un navigateur.

L’impact potentiel dépend en partie de l’isolation des processus. Mozilla n’avait pas terminé le déploiement de l’isolation des sites, selon le compte rendu de SecurityWeek sur ces résultats. Dans certaines circonstances, le contenu d’onglets distincts pouvait donc partager le même espace d’adressage, ce qui pourrait ouvrir la voie à une exposition de données entre onglets. Aucune attaque démontrant un tel scénario n’a été rapportée.

Dans GraalVM, les chercheurs ont identifié un chemin spéculatif susceptible de contourner un contrôle du bac à sable faisant appel au masquage de la mémoire, dans le mode de bac à sable le plus strict du moteur d’exécution. Ils ont pu provoquer de manière fiable la réutilisation d’adresses mémoire, mais les opérations de compilation et de ramasse-miettes ont effacé les entrées de branche obsolètes avant qu’ils ne puissent mener l’attaque à son terme.

Cette interférence a limité l’expérience, sans pour autant invalider la primitive. Les chercheurs ne la considèrent pas comme un obstacle fondamental. Oracle aurait déployé certaines mesures d’atténuation, mais les versions exactes des produits et les niveaux de correctif n’ont pas été divulgués.

Les protections matérielles compliquent l’attaque sans bloquer toutes les voies

Les protections du flux de contrôle, comme Indirect Branch Tracking d’Intel et Branch Target Identification d’Arm, peuvent compliquer l’exploitation de BTR. Elles n’éliminent toutefois pas toutes les techniques décrites par les chercheurs.

Sur les anciens processeurs Intel, des instructions peuvent être exécutées de manière spéculative avant que le contrôle du flux correspondant ne prenne effet. Selon les chercheurs, Lion Cove est la première génération Intel à ne pas présenter cette condition de concurrence particulière.

L’absence de cette condition de concurrence avec IBT ne garantit pas pour autant une immunité complète. Les chercheurs auraient contourné IBT sur des processeurs qui ne présentent pas cette condition lorsque l’obfuscation des constantes était désactivée. L’association d’IBT sans condition de concurrence et de l’obfuscation des constantes offre une protection nettement plus robuste.

Les fabricants de processeurs ont généralement renvoyé aux mécanismes de protection existants, comme IBPB, et rappelé que les logiciels devraient purger l’état des prédicteurs lorsque le rôle de la mémoire exécutable change. AMD a déclaré que la recherche n’avait pas mis en évidence de nouvelle vulnérabilité dans ses produits et a renvoyé les utilisateurs aux recommandations existantes sur Spectre v2. Les réponses d’Intel et d’Arm n’ont pas été rapportées.

Les administrateurs doivent privilégier les mises à jour du noyau et du microprogramme

Les opérateurs Linux devraient installer les dernières mises à jour du noyau disponibles pour leur distribution, en particulier sur les systèmes où les fonctionnalités cBPF non privilégiées sont accessibles. En l’absence de liste des versions corrigées, les avis de sécurité des distributions constituent le moyen le plus pratique d’identifier les paquets mis à jour.

Il convient également d’appliquer les mises à jour du microprogramme et du microcode. Elles peuvent renforcer les protections existantes contre l’exécution spéculative, même si la correction pratique de la réutilisation de mémoire BPF décrite dans les travaux repose sur une IBPB déclenchée par le logiciel.

Les équipes devraient vérifier si leurs charges de travail ont besoin du cBPF non privilégié, en particulier sur les hôtes partagés ou les systèmes exécutant du code provenant de locataires moins fiables. Désactiver une fonctionnalité sans connaître ses dépendances risque de perturber seccomp ou les mécanismes de filtrage. Toute restriction devrait donc être testée avant son déploiement.

Aucun indicateur de compromission propre à une attaque, hachage de fichier, domaine ou signature réseau n’a été divulgué. La détection doit donc se concentrer sur les usages locaux inhabituels des fonctionnalités BPF, le chargement inattendu de programmes non privilégiés et les activités suspectes autour de processus sensibles. Ces signaux ne sont pas propres à BTR, mais ils peuvent aider à repérer les conditions préalables utilisées dans l’attaque Linux démontrée.