CVE-2026-51302: Технические несоответствия

извините за кликбейтное название репозитория, но этот CVE — полностью и целиком LLM-галлюцинированный мусор; честно говоря, печально видеть, что такое принимает CNA, учитывая, насколько противоречивы заявления 💔

Вывод

CVE-2026-51302 не существует 😱

Опубликованный SQL не воспроизводит use-after-free ни в одном из релизов SQLite 3.41 под AddressSanitizer. Более того, заявленная первопричина полностью несовместима с затрагиваемым исходным кодом:

• exprComputeOperands() не существует в SQLite 3.41.0, 3.41.1 или 3.41.2;
• эта функция была добавлена 30 июня 2025 года, более чем через два года после SQLite 3.41;
• regFree1 — это целочисленный идентификатор регистра виртуальной машины, а не указатель на память в куче;
• sqlite3ReleaseTempReg() делает регистр доступным для повторного использования и не оставляет висячего C-указателя в regFree1;
• в версиях исходного кода, содержащих exprComputeOperands(), операнды вычисляются до освобождения временных регистров, вопреки последовательности, заявленной в advisory; и
• опубликованный SQL не содержит операнда-подзапроса и, следовательно, не задействует оптимизацию, ради которой была введена exprComputeOperands().

Эта запись CVE должна быть отклонена, и я подам возражение в CNA (MITRE) 😉

Утверждение из advisory

В advisory затрагиваемая версия указана как «SQLite 3.41», и приводится такой запрос:

SELECT CASE WHEN (1+3) THEN (5*8) ELSE (2/0) END FROM test;

В нём утверждается, что:

1. sqlite3ReleaseTempReg() освобождает память в куче, связанную с regFree1;
2. regFree1 остаётся висячей ссылкой;
3. exprComputeOperands() впоследствии обращается к освобождённой памяти; и
4. выполнение запроса на сборке с ASan даёт явный трейс heap-use-after-free.

Анализ исходного кода

sqlite3ReleaseTempReg() в SQLite 3.41

Амальгамация SQLite 3.41.0 определяет функцию следующим образом:

SQLITE_PRIVATE void sqlite3ReleaseTempReg(Parse *pParse, int iReg){
  if( iReg ){
    sqlite3VdbeReleaseRegisters(pParse, iReg, 1, 0, 0);
    if( pParse->nTempReg<ArraySize(pParse->aTempReg) ){
      pParse->aTempReg[pParse->nTempReg++] = iReg;
    }
  }
}

Функция принимает iReg как int. Она сохраняет это целое число в pParse->aTempReg, чтобы номер регистра мог быть выделен снова:

SQLITE_PRIVATE int sqlite3GetTempReg(Parse *pParse){
  if( pParse->nTempReg==0 ){
    return ++pParse->nMem;
  }
  return pParse->aTempReg[--pParse->nTempReg];
}

Это управление временем жизни регистров в процессе генерации программы VDBE. В advisory regFree1 описан так, будто это переживший освобождение указатель на память из кучи. На самом деле это не так:

int regFree1 = 0, regFree2 = 0;
int r1, r2;

r1 = exprVectorRegister(pParse, pLeft, i, regLeft, &pL, &regFree1);
r2 = exprVectorRegister(pParse, pRight, i, regRight, &pR, &regFree2);
codeCompare(pParse, pL, pR, opx, r1, r2, addrDone, p5, isCommuted);
sqlite3ReleaseTempReg(pParse, regFree1);
sqlite3ReleaseTempReg(pParse, regFree2);

Сгенерированное сравнение потребляет идентификаторы регистров до того, как они будут освобождены для повторного использования.

exprComputeOperands() не существовала

Поиск по blame в зеркале Git показал, что exprComputeOperands() была введена коммитом:

e24f20a4f5a6d26cdaece58eff77619a4ee757b9
2025-06-30T10:30:47Z
Factor out the code that tries to avoid evaluating subquery operands if the other operand is NULL into a subroutine, so that it can be more easily reused by other parts of the code generator.

Эта функция отсутствует во всех трёх официальных амальгамациях SQLite 3.41. Уязвимость в SQLite 3.41 не может проходить по пути исполнения через функцию, которая была введена в 2025 году, ну правда, MITRE? 🥲

Заявленный порядок операций перевёрнут

В современном исходном коде SQLite сокращённый порядок вызовов в sqlite3ExprIfTrue() выглядит так:

addrIsNull = exprComputeOperands(
    pParse, pExpr, &r1, &r2, &regFree1, &regFree2);

codeCompare(
    pParse, pExpr->pLeft, pExpr->pRight, op,
    r1, r2, dest, jumpIfNull, ExprHasProperty(pExpr, EP_Commuted));

/* Other switch cases and generated-bytecode handling occur here. */

sqlite3ReleaseTempReg(pParse, regFree1);
sqlite3ReleaseTempReg(pParse, regFree2);

exprComputeOperands() формирует идентификаторы регистров. Вызывающий код сначала потребляет их, а затем освобождает. В advisory же утверждается, что sqlite3ReleaseTempReg() выполняется первой, а exprComputeOperands() позже обращается к освобождённому объекту.

Опубликованный запрос не соответствует современной функции

exprComputeOperands() была введена, чтобы избегать вычисления дорогостоящего операнда-подзапроса, когда другой операнд равен NULL. Опубликованное выражение:

CASE WHEN (1+3) THEN (5*8) ELSE (2/0) END

содержит арифметические операции и выражение CASE, но не содержит операнда-подзапроса. Приведённое для этого запроса обоснование не соответствует условиям вызова функции.

Дополнительно

Окружение

vm, кстати

Debian GNU/Linux 13 (trixie)
Clang 19.1.7
AddressSanitizer enabled
Optimisation level: -O1
Frame pointers retained
Sanitizer recovery disabled

SHA амальгамаций:

3.41.0  146ce189b67fdbefbf2d72cdc81e198d07ff643614cc9102e9bf063255e8e7e1
3.41.1  df0d54bf246521360c8148f64e7e5ad07a4665b4f902339e844f4c493d535ff5
3.41.2  01df06a84803c1ab4d62c64e995b151b2dbcf5dbc93bbc5eee213cb18225d987
3.53.3  646421e12aac110282ef8cc68f1a62d4bb15fc7b8f09da0b53e29ee690500431

Ссылки 😁

• Публичный advisory: https://github.com/programmervuln/cveadvisory-/blob/main/CVE-2026-51302
• Запись CVE: https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/51xxx/CVE-2026-51302.json
• История релизов SQLite: https://www.sqlite.org/changes.html
• Релиз SQLite 3.41.0: https://www.sqlite.org/releaselog/3_41_0.html
• Релиз SQLite 3.41.1: https://www.sqlite.org/releaselog/3_41_1.html
• Релиз SQLite 3.41.2: https://www.sqlite.org/releaselog/3_41_2.html
• Появление функции: https://github.com/sqlite/sqlite/commit/e24f20a4f5a6d26cdaece58eff77619a4ee757b9