LoongBleed

中文

LoongBleed est une vulnérabilité matérielle, conceptuellement similaire à ZenBleed (CVE-2023-20593) — affectant les processeurs Loongson LA464/LA664 qui implémentent à la fois LSX (SIMD 128 bits) et LASX (SIMD 256 bits).

Sur LoongArch, les registres LSX $vr (128 bits) aliasent la moitié inférieure des registres LASX $xr (256 bits). Les instructions LSX et les opérations de base en virgule flottante sont uniquement définies pour opérer sur les 128 bits inférieurs (ou un sous-ensemble de ceux-ci) ; les bits supérieurs du registre $xr correspondant sont indéfinis. Cependant, en raison d'un défaut microarchitectural, ces opérations peuvent fuiter des données via les 128 bits supérieurs de $xr, exposant des données sensibles à travers les frontières de privilèges ou entre les frères SMT.

Note sur la découverte indépendante — Le même défaut matériel sous-jacent a été découvert et publié indépendamment par des chercheurs du CISPA Helmholtz Center for Information Security sous le nom de LoongLeak (https://loongleakattack.com/), présenté à USENIX Security 2026 sous le titre « LoongLeak: Architectural Cross-Privilege-Boundary Data Leakage on LoongArch CPUs ». Notre travail a été développé indépendamment de l'équipe LoongLeak ; les deux groupes sont parvenus à la même conclusion : les processeurs Loongson LA464/LA664 fuientent des données via les bits supérieurs indéfinis des registres LASX $xr. Notez que les instructions que nous utilisons pour déclencher la fuite ne sont pas identiques à celles rapportées dans l'article LoongLeak : notre PoC repose sur un ensemble différent de gadgets (vor.v, vld, fld.d, fld.s) pour reproduire le même défaut matériel sous-jacent. De plus, comme la fuite peut être déclenchée par de pures instructions registre-registre telles que vor.v (aucun chargement mémoire impliqué), notre analyse suggère que la cause racine est probablement la réutilisation de registres physiques : les bits supérieurs d'un registre physique réutilisé ne sont pas effacés, fuitant des données résiduelles d'un occupant précédent du registre. Cela diffère de l'analyse de l'article LoongLeak, qui attribue les données fuitées au cache de données L1.

Chronologie

• 2026-05-12 — Vulnérabilité signalée à Loongson.
• 2026-06-09 — Loongson a confirmé qu'il s'agit d'une découverte indépendante d'une vulnérabilité déjà connue.
• 2026-08-17 — Loongson a officiellement publié une annonce concernant la vulnérabilité LoongLeak (annonce officielle).
• 2026-08-18 — Ce dépôt a été rendu public.

Fonctionnement

La preuve de concept fonctionne comme suit :

1. Charger des données entièrement nulles dans un registre $xrN via xvld.
2. Exécuter une instruction (LSX ou virgule flottante de base) qui ne devrait toucher que les 128 bits inférieurs (ou une partie de ceux-ci).
3. Restocker le registre complet de 256 bits via xvst.
4. Comparer les 256 bits avec la valeur d'origine. Si les 128 bits supérieurs ou inférieurs diffèrent de la valeur nulle attendue, une fuite s'est produite.

Le PoC exécute ce gadget de manière répétée sur 16 registres vectoriels architecturaux ($xr0–$xr15) sur des threads épinglés à des cœurs physiques. Les valeurs non nulles qui apparaissent après l'instruction indiquent que la microarchitecture a propagé des données résiduelles ou inter-contextes dans l'état des registres architecturaux.

Gadgets

Le PoC prend en charge plusieurs instructions de test, sélectionnables via --gadget :

Sur LA664, les quatre gadgets exposent la fuite, fuitant au maximum 192 bits par vecteur. Sur LA464, vld, fld.d et fld.s fuitent (au maximum 224 bits par vecteur) ; le gadget par défaut vor.v ne fuit pas sur LA464.

Utilisation

Usage: ./loongbleed_poc [OPTIONS]

Options:
  -a, --all                Launch one thread pinned to each physical core.
                           By default only thread on CPU 0 is launched.
  -g, --gadget [vor|vld|fld.d|fld.s]
                           Use different instructions for testing.
  -h, --help               Show this help and exit.

Exemples

# Single-thread mode on CPU 0
./run.sh

# Single-thread mode with vld gadget (required for LA464)
./run.sh --gadget vld

# All physical cores, default gadget
./run.sh -a

# All cores with fld.d gadget
./run.sh --all --gadget fld.d

Scénarios d'attaque

LA664 (par ex., Loongson 3C6000/D)

Un thread victime traite des données sensibles sur un CPU logique tandis que le PoC sonde les registres sur son frère SMT. Le thread espion peut observer des fragments des données de la victime dans les bits supérieurs fuités.

# Terminal 1 — start LoongBleed on CPU 0
./run.sh

# Terminal 2 — victim workload on the SMT sibling (CPU 1)
while true; do numactl -C 1 sort < /etc/shadow > /dev/null; done

Pour une configuration automatisée, utilisez le script fourni :

./poc_la664.sh

Cela lance une charge de travail sort sur le CPU 1 (le frère SMT du CPU 0) et démarre LoongBleed sur le CPU 0 avec le gadget par défaut.

LA464

Un thread victime traite des données sensibles sur un CPU tandis que le PoC sonde les registres sur le même cœur. Nécessite --gadget vld car le gadget par défaut vor.v ne fuit pas sur LA464.

# Terminal 1 — start LoongBleed on CPU 0
./run.sh --gadget vld

# Terminal 2 — victim workload on the same core
while true; do numactl -C 0 sort < /etc/shadow > /dev/null; done

Pour une configuration automatisée :

./poc_la464.sh

Cela lance une charge de travail sort sur le CPU 0 et démarre LoongBleed avec --gadget vld.

Compilation

Le PoC est un programme C++ en un seul fichier sans dépendances externes.

g++ -std=c++11 -O2 -march=native -pthread -o loongbleed_poc loongbleed_poc.cpp

Ou utilisez le script fourni :

./run.sh
# or, on LA464:
./run.sh --gadget vld

Interprétation de la sortie

Lorsqu'une fuite est détectée et que les octets fuités contiennent une séquence d'au moins 8 caractères ASCII imprimables contigus (0x20–0x7e), le PoC affiche :

[cpu   0] LEAK chunk=14 data=0x7461646e756f4620_6572617774666f53_0000000000000000_0000000000000000 ascii=............Software Foundat

• cpu — le CPU logique auquel le thread détecteur est épinglé
• chunk — lequel des 16 emplacements de registres vectoriels ($xr0–$xr15) a déclenché
• data — la valeur complète de 256 bits relue depuis $xrN après l'instruction, affichée sous la forme data3_data2_data1_data0 où :
  • data0 = bits [63:0] (64 bits les plus bas du résultat)
  • data1 = bits [127:64] (64 bits supérieurs de la moitié inférieure de 128 bits)
  • data2 = bits [191:128] (64 bits inférieurs de la moitié supérieure de 128 bits)
  • data3 = bits [255:192] (64 bits supérieurs de la moitié supérieure de 128 bits)
• ascii — interprétation imprimable de la fenêtre de 28 octets fuitée (octets 4–31 du résultat, c'est-à-dire les 224 bits supérieurs moins les 32 bits les plus bas). Les octets non imprimables sont affichés sous la forme ..

Toute valeur non nulle dans les 128 bits supérieurs (data2 ou data3) indique une fuite de données microarchitecturale.

Comment cela a été découvert

La vulnérabilité a été découverte lors de la lecture de l'article de Chips and Cheese « Loongson's LSX and LASX Vector Extensions ». L'article notait que les instructions vectorielles peuvent laisser derrière elles des résidus de données aléatoires. Cela nous a conduit à émettre l'hypothèse que le renommage de registres pourrait ne pas effacer les registres — un mécanisme similaire à ZenBleed — ce qui permettrait en théorie de fuiter des données de l'espace noyau. Nous avons ensuite mené des expériences pour vérifier cette hypothèse ; la fuite se produit effectivement et se reproduit sur le Loongson 3A5000 et le 3A6000.

Avertissement

Ce projet est fourni à des fins éducatives et de recherche en sécurité uniquement.