CVE-2026-51302: Inconsistências Técnicas

desculpe pelo nome clickbait do repositório, mas este CVE é lixo completo e totalmente alucinado por LLM, sinceramente triste ver uma CNA aceitar isso com o quão inconsistentes são as alegações 💔

Conclusão

CVE-2026-51302 não é real 😱

O SQL publicado não reproduz um use-after-free em nenhuma versão do SQLite 3.41 sob AddressSanitizer. Mais importante ainda, a causa raiz declarada é totalmente incompatível com o código-fonte afetado:

• exprComputeOperands() não existe no SQLite 3.41.0, 3.41.1 ou 3.41.2;
• essa função foi introduzida em 30 de junho de 2025, mais de dois anos após o SQLite 3.41;
• regFree1 é um identificador inteiro de registrador da máquina virtual, não um ponteiro para armazenamento no heap;
• sqlite3ReleaseTempReg() torna um registrador disponível para reutilização e não deixa um ponteiro C pendente em regFree1;
• em versões do código-fonte que contêm exprComputeOperands(), os operandos são computados antes de os registradores temporários serem liberados, ao contrário da sequência declarada no advisory; e
• o SQL publicado não contém operando de subconsulta e, portanto, não exercita a otimização para a qual exprComputeOperands() foi introduzida.

Este registro de CVE deveria ser rejeitado e vou abrir uma disputa de CNA junto à MITRE 😉

Alegações do Advisory

O advisory identifica a versão afetada como "SQLite 3.41" e fornece esta consulta:

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

Ele alega que:

1. sqlite3ReleaseTempReg() libera memória do heap associada a regFree1;
2. regFree1 permanece como uma referência pendente;
3. exprComputeOperands() acessa subsequentemente a memória liberada; e
4. executar a consulta contra um build com ASan produz um trace claro de heap-use-after-free.

Análise do Código-Fonte

sqlite3ReleaseTempReg() no SQLite 3.41

O amalgamation do SQLite 3.41.0 define a função da seguinte forma:

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;
    }
  }
}

A função recebe iReg como um int. Ela registra esse inteiro em pParse->aTempReg para que o número do registrador possa ser alocado novamente:

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

Isso é gerenciamento de tempo de vida de registradores durante a geração do programa VDBE. O advisory descreve regFree1 como se fosse um ponteiro sobrevivente para armazenamento de heap liberado. Não é:

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);

A comparação gerada consome os identificadores de registrador antes de eles serem liberados para reutilização.

exprComputeOperands() não existia

Uma busca blame no espelho Git descobriu que exprComputeOperands() foi introduzida por:

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.

A função está ausente nos três amalgamations oficiais do SQLite 3.41. Uma vulnerabilidade no SQLite 3.41 não pode seguir um caminho de execução através de uma função que foi introduzida em 2025, qual é, MITRE, sério? 🥲

A ordem de operação alegada está invertida

No código-fonte moderno do SQLite, a ordem de chamada resumida em 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() produz os identificadores de registrador. O chamador os consome e depois os libera. O advisory, em vez disso, alega que sqlite3ReleaseTempReg() executa primeiro e exprComputeOperands() acessa posteriormente o objeto liberado.

A consulta publicada não corresponde à função moderna

exprComputeOperands() foi introduzida para evitar avaliar um operando de subconsulta caro quando o outro operando é NULL. A expressão publicada:

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

contém operações aritméticas e uma expressão CASE, mas nenhum operando de subconsulta. A justificativa dada para esta consulta não corresponde às condições de chamada da função.

Extras

Ambiente

vm a propósito

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

SHAs dos amalgamations:

3.41.0  146ce189b67fdbefbf2d72cdc81e198d07ff643614cc9102e9bf063255e8e7e1
3.41.1  df0d54bf246521360c8148f64e7e5ad07a4665b4f902339e844f4c493d535ff5
3.41.2  01df06a84803c1ab4d62c64e995b151b2dbcf5dbc93bbc5eee213cb18225d987
3.53.3  646421e12aac110282ef8cc68f1a62d4bb15fc7b8f09da0b53e29ee690500431

Compilado de links 😁

• Advisory público: https://github.com/programmervuln/cveadvisory-/blob/main/CVE-2026-51302
• Registro CVE: https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/51xxx/CVE-2026-51302.json
• Histórico de versões do SQLite: https://www.sqlite.org/changes.html
• Versão SQLite 3.41.0: https://www.sqlite.org/releaselog/3_41_0.html
• Versão SQLite 3.41.1: https://www.sqlite.org/releaselog/3_41_1.html
• Versão SQLite 3.41.2: https://www.sqlite.org/releaselog/3_41_2.html
• Introdução da função: https://github.com/sqlite/sqlite/commit/e24f20a4f5a6d26cdaece58eff77619a4ee757b9