20000419/cve-2026-39113Advisory und AddressSanitizer-Reproduzierer für einen SQLite-SQLAR-Heap-Pufferüberlauf, der durch einen manipulierten SZ-Wert ausgelöst wird und eine verkürzte Speicherzuweisung sowie einen zlib-Schreibzugriff außerhalb der Grenzen verursacht.
CVE-2026-39113 ist ein Heap-Pufferüberlauf in der optionalen SQLAR-Erweiterung von SQLite. In einer Anwendung, die die Erweiterung geladen hat, kann ein Angreifer, der sqlar_uncompress() mit einem kontrollierten komprimierten Blob und einer kontrollierten Größe aufrufen kann, dazu bringen, dass zlib auf einem LP64-System über eine Heap-Allokation hinaus schreibt. Dabei handelt es sich um einen Speichersicherheits-Grenzfehler innerhalb des Host-Prozesses; es ist kein Problem beim Parsen von SQLite-Datenbankdateien, keine Authentifizierungsumgehung und auch kein Fehler, der in jeder Standard-SQLite-Bereitstellung erreichbar ist.
Das anfällige Verhalten wurde am 2026-03-11 durch Git-Commit 169f68e (Fossil-Check-in 8bdc0d485e3ad0c7...) eingeführt und am 2026-04-01 durch Git-Commit 34e139d (Fossil-Check-in 6194f3b5314ef98b...) korrigiert. Der betroffene Bereich umfasst Quellschnappschüsse und benutzerdefinierte Builds von 169f68e bis zum Parent von 34e139d. Keine offizielle SQLite-Version wurde als anfällig verifiziert: SQLite 3.52.0 stammt aus der Zeit vor der Einführung, und SQLite 3.53.0 enthält sowohl die einführende Änderung als auch den Fix. SQLite 3.53.0 ist daher die erste offizielle Version mit dem korrigierten Code und keine betroffene Version.
Ich habe die exakte anfällige Revision, die einführende und die korrigierende Änderung sowie die Release-Schnappschüsse von 3.52.0 und 3.53.0 überprüft. Außerdem habe ich die aufbewahrte Ausgabe eines autorisierten Laufs in einer Wegwerf-Umgebung mit WSL2 Ubuntu 24.04 geprüft. AddressSanitizer erkannte einen Heap-Buffer-Overflow gefolgt von Prozessbeendigung, was native Heap-Korruption und Denial of Service belegt. Codeausführung wurde nicht demonstriert.
SQLAR ist ein SQLite-Archivformat. Die optionale Erweiterung in ext/misc/sqlar.c registriert sqlar_compress() und sqlar_uncompress() als SQL-Funktionen. Sie ist nicht Bestandteil jeder Anwendung, die SQLite verwendet; der anfällige Pfad erfordert, dass die Erweiterung vorhanden und geladen ist.
Für diesen Bericht kontrolliert Mallory die Blob- und SZ-Argumente, die an Folgendes übergeben werden:
SELECT sqlar_uncompress(?1, ?2);
Die getestete Umgebung hatte einen 32-Bit-int, ein 64-Bit-sqlite3_int64 und zlib uLongf. Die Funktion sollte mindestens so viel Speicher allokieren, wie zlib schreiben darf. Stattdessen wandelt der anfällige Quellcode die 64-Bit-Größe in den 32-Bit-Parametertyp von sqlite3_malloc() um, während der volle Wert für uncompress() erhalten bleibt.
Der anfällige Quellschnappschuss gab während der Konfiguration Configuring SQLite version 3.53.0 aus. Diese Entwicklungsversionszeichenfolge darf nicht mit der offiziellen SQLite-3.53.0-Version vom 2026-04-09 verwechselt werden, deren Quellcode den Fix enthält.
In der bewerteten Revision liest sqlarUncompressFunc() in ext/misc/sqlar.c die angreiferkontrollierte Größe als 64-Bit-Ganzzahl:
sqlite3_int64 sz;
sz = sqlite3_value_int64(argv[1]);
Wenn sz positiv ist und sich von der Länge des Eingabe-Blobs unterscheidet, wird derselbe Wert auf zwei inkompatible Arten verwendet:
uLongf szf = sz;
const Bytef *pData = sqlite3_value_blob(argv[0]);
Bytef *pOut = sqlite3_malloc(sz);
if( pOut==0 ){
sqlite3_result_error_nomem(context);
}else if( Z_OK!=uncompress(pOut, &szf, pData, nData) ){
sqlite3_result_error(context, "error in uncompress()", -1);
}
In dieser Revision deklariert SQLite sqlite3_malloc(int). Beim getesteten LP64-Build wurde der PoC-Wert 4294967328 (0x100000020) bei der Übergabe an diese API zu 32, während szf den vollständigen 64-Bit-Wert behielt. SQLite allokierte also eine kleine Speichermenge, aber zlib wurde mitgeteilt, dass der Ausgabepuffer mehr als 4 GiB fassen könne. Das Dekomprimieren eines 42-Byte-Blobs, der 4096 Byte Daten repräsentiert, überschritt daraufhin die Allokationsgrenze.
Die Diskrepanz gelangte in das Projekt, als die Änderung vom 2026-03-11 sqlite3_value_int() durch sqlite3_value_int64() ersetzte, ohne die Allokations-API zu ändern. Die Quellcode-Prüfung von SQLite 3.52.0 zeigt die frühere 32-Bit-Lesung; daher war die Diskrepanz zwischen voller Breite und kurzer Allokation dort nicht vorhanden. Der Fix vom 2026-04-01 änderte die Allokation auf sqlite3_malloc64(sz). Die Quellcode-Prüfung des offiziellen 3.53.0-Tags bestätigt diesen korrigierten Aufruf.
Die demonstrierte Primitive ist ein Out-of-Bounds-Heap-Schreibvorgang im Prozess, der SQLite hostet. Der aufbewahrte Lauf zeigt, dass AddressSanitizer das erste ungültige Ein-Byte-Schreiben unmittelbar nach einer über sqlite3_malloc() allokierten 40-Byte-Heap-Region erkennt, gefolgt von einem Abbruch. Dies stützt direkt Prozessabsturz und Denial of Service.
Für die Ausnutzung ist alles Folgende erforderlich:
sqlar_uncompress() mit einem kontrollierten Blob und SZ-Wert aufrufen kann;int 32 Bit breit ist, während sqlite3_int64 und zlib uLongf 64 Bit breit sind; undDer PoC kontrolliert die dekomprimierten Bytes, was für den Schweregrad der nativen Heap-Korruption relevant ist. Diese Primitive in Codeausführung umzuwandeln, würde jedoch vom Allokator-Layout, dem umgebenden Prozesszustand, Schutzmaßnahmen und einem geeigneten Weg auf Anwendungsebene abhängen. Eine solche Kette wurde nicht getestet oder demonstriert; daher beansprucht dieser Bericht keine Codeausführung.
Der aufbewahrte Lauf enthielt keine Laufzeit-Negativkontrolle gegen die korrigierte Revision. Zwei Kontrollen auf Quellcode-Ebene grenzen die Erklärung ein: SQLite 3.52.0 liest die Größe mit der 32-Bit-API, und der offizielle 3.53.0-Quellcode allokiert mit sqlite3_malloc64(). Diese Prüfungen stützen die identifizierte Einführung und den Fix, werden aber nicht als ausgeführte Tests gegen das korrigierte Ziel dargestellt. Die Verbreitung von Anwendungen, die diese optionale Erweiterung laden, ist unbekannt.
Das Repository enthält:
poc/verify_sqlar_poc.c, das ein 4096-Byte-Payload erzeugt, es komprimiert, sqlar.so lädt und SZ = 4294967328 bindet;poc/reproduce.sh, das gepinnte SQLite- und zlib-Revisionen klont, sie mit AddressSanitizer baut, die Erweiterung und den Harness kompiliert und den Auslöser ausführt; undevidence/asan-summary.txt, eine pfadnormalisierte Zusammenfassung des beobachteten autorisierten Laufs.Führen Sie den Reproducer nur in einer Wegwerf-Linux- oder WSL-Umgebung aus. Er löst absichtlich Speicherkorruption und einen AddressSanitizer-Abbruch aus. Das Skript erfordert git, make, einen C-Compiler, Standard-Buildwerkzeuge und Netzwerkzugriff:
chmod +x poc/reproduce.sh
./poc/reproduce.sh
Der Reproducer wurde am 2026-08-21 erneut unter Ubuntu 24.04 in WSL2 ausgeführt und erzeugte denselben AddressSanitizer-Befund. Die relevante Ausgabe war:
env: sizeof(int)=4 sizeof(sqlite3_int64)=8 sizeof(uLongf)=8
payload: plain=4096 compressed=42 evil_sz=4294967328 low32=32
ERROR: AddressSanitizer: heap-buffer-overflow
WRITE of size 1
#0 inflate_fast zlib/inffast.c:252
#4 uncompress zlib/uncompr.c:100
#5 sqlarUncompressFunc sqlite/ext/misc/sqlar.c:97
The write occurred immediately after a 40-byte heap region.
SUMMARY: AddressSanitizer: heap-buffer-overflow in inflate_fast
ABORTING
PoC exit status: 1
Diese Ausgabe zeigt die inkompatiblen Typbreiten und die präparierte Größe, den zlib-Schreibvorgang, den Aufruf von sqlarUncompressFunc() und die Verletzung der Allokationsgrenze. Das Reproduktionsskript löscht sein temporäres Build-Verzeichnis beim Beenden, sofern nicht KEEP_BUILD=1 gesetzt ist.
Upstream hat die anfällige Allokation in Commit 34e139d korrigiert:
- Bytef *pOut = sqlite3_malloc(sz);
+ Bytef *pOut = sqlite3_malloc64(sz);
Dies hält die Allokationsbreite konsistent mit dem positiven 64-Bit-sz-Wert, der in uLongf szf erhalten bleibt und an zlib übergeben wird. Der korrigierte Code ist in der offiziellen SQLite 3.53.0 enthalten. Benutzer von Quellschnappschüssen oder benutzerdefinierten Builds, die das anfällige Intervall enthalten, sollten auf 34e139d oder neuer aktualisieren. Anwendungen, die SQLAR nicht benötigen, sollten das Laden der Erweiterung vermeiden, und Anwendungen, die sie verwenden, sollten verhindern, dass nicht vertrauenswürdige Aufrufer beliebige Argumente an sqlar_uncompress() übergeben.
Ein gezielter Regressionstest sollte die SQL-Funktion mit einem gültigen komprimierten Blob und einem SZ-Wert über INT_MAX ausführen, dessen untere 32 Bit klein sind. Er sollte überprüfen, dass der korrigierte Build keine abgeschnittene Allokation durchführt, und normale erfolgreiche Dekomprimierung sowie Fehlerfälle bei ungültiger Eingabe als Kontrollen beibehalten.
CVE-2026-39113 betrifft nur SQLite-Quellschnappschüsse und benutzerdefinierte Builds von 169f68e bis zum Parent von 34e139d, wenn die optionale SQLAR-Erweiterung geladen ist und angreiferkontrollierte Aufrufe sqlar_uncompress() in einem LP64-Build erreichen. Eine 64-Bit-Größe wurde durch sqlite3_malloc(int) verkleinert, während zlib den vollen Wert beibehielt, was zu einem durch AddressSanitizer bestätigten Heap-Buffer-Overflow und Prozessabbruch führte. Keine offizielle SQLite-Version wurde als anfällig verifiziert, und Codeausführung wurde nicht demonstriert. Die Upstream-Änderung auf sqlite3_malloc64(sz) ist in der offiziellen SQLite 3.53.0 enthalten und beseitigt die Allokationsbreiten-Diskrepanz.