LoongBleed

中文

LoongBleed ist eine Hardware-Schwachstelle, konzeptionell ähnlich zu ZenBleed (CVE-2023-20593) — die Loongson LA464/LA664-Prozessoren betrifft, welche sowohl LSX (128-Bit-SIMD) als auch LASX (256-Bit-SIMD) implementieren.

Auf LoongArch überlagern die LSX-$vr-Register (128-Bit) die untere Hälfte der LASX- $xr-Register (256-Bit). LSX-Instruktionen und grundlegende Gleitkommaoperationen sind nur dafür definiert, auf den unteren 128 Bits (oder einer Teilmenge davon) zu operieren; die oberen Bits des entsprechenden $xr-Registers sind undefiniert. Aufgrund eines mikroarchitektonischen Fehlers können diese Operationen jedoch Daten durchsickern lassen über die oberen 128 Bits von $xr und dabei sensible Daten über Privilegiengrenzen hinweg oder zwischen SMT-Geschwistern offenlegen.

Hinweis zur unabhängigen Entdeckung — Derselbe zugrunde liegende Hardwarefehler wurde unabhängig davon von Forschern am CISPA Helmholtz Center for Information Security entdeckt und als LoongLeak (https://loongleakattack.com/) veröffentlicht, präsentiert auf der USENIX Security 2026 als „LoongLeak: Architectural Cross-Privilege-Boundary Data Leakage on LoongArch CPUs". Unsere Arbeit wurde unabhängig vom LoongLeak-Team entwickelt; beide Gruppen kamen zu demselben Schluss, dass Loongson LA464/LA664-Prozessoren Daten über die undefinierten oberen Bits der LASX- $xr-Register durchsickern lassen. Beachten Sie, dass die Instruktionen, die wir zum Auslösen des Leaks verwenden, nicht identisch mit denen sind, die im LoongLeak-Paper berichtet werden: Unser PoC stützt sich auf einen anderen Satz von Gadgets (vor.v, vld, fld.d, fld.s), um denselben zugrunde liegenden Hardwarefehler zu reproduzieren. Da der Leak zudem durch reine Register-zu-Register-Instruktionen wie vor.v ausgelöst werden kann (kein Speicherladevorgang beteiligt), legt unsere Analyse nahe, dass die Ursache wahrscheinlich in der Wiederverwendung physischer Register liegt: Die oberen Bits eines wiederverwendeten physischen Registers werden nicht gelöscht, wodurch veraltete Daten eines vorherigen Registerinhabers durchsickern. Dies unterscheidet sich von der Analyse des LoongLeak-Papers, welches die durchgesickerten Daten dem L1-Datencache zuschreibt.

Zeitleiste

• 2026-05-12 — Die Schwachstelle wurde an Loongson gemeldet.
• 2026-06-09 — Loongson bestätigte, dass es sich um eine unabhängige Entdeckung einer bereits bekannten Schwachstelle handelt.
• 2026-08-17 — Loongson veröffentlichte offiziell eine Ankündigung bezüglich der LoongLeak-Schwachstelle (offizielle Ankündigung).
• 2026-08-18 — Dieses Repository wurde öffentlich gemacht.

Funktionsweise

Der Proof-of-Concept funktioniert wie folgt:

1. Laden von Null-Daten in ein $xrN-Register via xvld.
2. Ausführen einer Instruktion (LSX oder grundlegende Gleitkommaoperation), die nur die unteren 128 Bits (oder einen Teil davon) berühren sollte.
3. Zurückschreiben des vollständigen 256-Bit-Registers via xvst.
4. Vergleichen aller 256 Bits mit dem ursprünglichen Wert. Wenn die oberen oder unteren 128 Bits vom erwarteten Nullwert abweichen, ist ein Leak aufgetreten.

Der PoC führt dieses Gadget wiederholt über 16 architektonische Vektorregister ($xr0–$xr15) auf Threads aus, die an physische Kerne gebunden sind. Werte ungleich Null, die nach der Instruktion auftreten, zeigen an, dass die Mikroarchitektur veraltete oder kontextübergreifende Daten in den architektonischen Registerzustand übernommen hat.

Gadgets

Der PoC unterstützt mehrere Testinstruktionen, auswählbar über --gadget:

Auf LA664 legen alle vier Gadgets den Leak offen und lassen höchstens 192 Bits pro Vektor durchsickern. Auf LA464 leaken vld, fld.d und fld.s (höchstens 224 Bits pro Vektor); das Standard-Gadget vor.v leakt auf LA464 nicht.

Verwendung

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.

Beispiele

# 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

Angriffsszenarien

LA664 (z. B. Loongson 3C6000/D)

Ein Opfer-Thread verarbeitet sensible Daten auf einer logischen CPU, während der PoC Register auf seinem SMT-Geschwister abfragt. Der schnüffelnde Thread kann Fragmente der Daten des Opfers in den durchgesickerten oberen Bits beobachten.

# 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

Für ein automatisiertes Setup verwenden Sie das bereitgestellte Skript:

./poc_la664.sh

Dies startet eine sort-Arbeitslast auf CPU 1 (dem SMT-Geschwister von CPU 0) und startet LoongBleed auf CPU 0 mit dem Standard-Gadget.

LA464

Ein Opfer-Thread verarbeitet sensible Daten auf einer CPU, während der PoC Register auf demselben Kern abfragt. Erfordert --gadget vld, da das Standard-vor.v- Gadget auf LA464 nicht leakt.

# 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

Für ein automatisiertes Setup:

./poc_la464.sh

Dies startet eine sort-Arbeitslast auf CPU 0 und startet LoongBleed mit --gadget vld.

Erstellung

Der PoC ist ein einteiliges C++-Programm ohne externe Abhängigkeiten.

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

Oder verwenden Sie das bereitgestellte Skript:

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

Interpretation der Ausgabe

Wenn ein Leak erkannt wird und die durchgesickerten Bytes eine Folge von mindestens 8 zusammenhängenden druckbaren ASCII-Zeichen (0x20–0x7e) enthalten, gibt der PoC aus:

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

• cpu — die logische CPU, an die der erkennende Thread gebunden ist
• chunk — welcher der 16 Vektorregister-Slots ($xr0–$xr15) ausgelöst hat
• data — der vollständige 256-Bit-Wert, der nach der Instruktion aus $xrN zurückgelesen wurde, dargestellt als data3_data2_data1_data0, wobei:
  • data0 = Bits [63:0] (niedrigste 64 Bits des Ergebnisses)
  • data1 = Bits [127:64] (obere 64 Bits der unteren 128-Bit-Hälfte)
  • data2 = Bits [191:128] (untere 64 Bits der oberen 128-Bit-Hälfte)
  • data3 = Bits [255:192] (obere 64 Bits der oberen 128-Bit-Hälfte)
• ascii — druckbare Interpretation des durchgesickerten 28-Byte-Fensters (Bytes 4–31 des Ergebnisses, d. h. die oberen 224 Bits minus der niedrigsten 32 Bits). Nicht druckbare Bytes werden als . dargestellt.

Jeder Wert ungleich Null in den oberen 128 Bits (data2 oder data3) weist auf ein mikroarchitektonisches Datenleck hin.

Wie es entdeckt wurde

Die Schwachstelle wurde beim Lesen des Chips and Cheese-Artikels „Loongson's LSX and LASX Vector Extensions" entdeckt. Der Artikel merkte an, dass Vektorinstruktionen einige zufällige Datenreste hinterlassen können. Dies führte uns zu der Hypothese, dass Register-Renaming die Register möglicherweise nicht löscht — ein Mechanismus ähnlich zu ZenBleed — was theoretisch das Durchsickern von Kernel-Speicherdaten ermöglichen würde. Wir führten daraufhin Experimente durch, um diese Hypothese zu überprüfen; der Leak tritt tatsächlich auf und lässt sich sowohl auf dem Loongson 3A5000 als auch auf dem 3A6000 reproduzieren.

Haftungsausschluss

Dieses Projekt wird ausschließlich für Bildungs- und Sicherheitsforschungszwecke bereitgestellt.