抱歉使用了标题党式的仓库名称，但这个 CVE 完全是 LLM 幻觉生成的垃圾内容，看到 CNA 竟然接受了如此不一致的声明，实在令人遗憾 💔
CVE-2026-51302 并不存在 😱
公开的 SQL 无法在 AddressSanitizer 下于任何 SQLite 3.41 版本中复现释放后使用（use-after-free）。更重要的是，所声称的根本原因与受影响源码完全不符：
exprComputeOperands() 在 SQLite 3.41.0、3.41.1 和 3.41.2 中不存在；regFree1 是一个整数虚拟机寄存器标识符，而不是指向堆存储的指针；sqlite3ReleaseTempReg() 使寄存器可供复用，并不会在 regFree1 中留下悬垂的 C 指针；exprComputeOperands() 的源码版本中，操作数在临时寄存器释放之前计算，与公告所述的顺序相反；exprComputeOperands() 所引入的优化。该 CVE 记录应当被拒绝，我将向 MITRE 提出 CNA 争议 😉
该公告将受影响版本标识为“SQLite 3.41”，并提供了以下查询：
SELECT CASE WHEN (1+3) THEN (5*8) ELSE (2/0) END FROM test;
它声称：
sqlite3ReleaseTempReg() 释放与 regFree1 关联的堆内存；regFree1 仍然作为悬垂引用存在；exprComputeOperands() 随后访问了已释放的内存；SQLite 3.41.0 合并版（amalgamation）中该函数定义如下：
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 程序生成期间的寄存器生命周期管理。公告将 regFree1 描述为指向已释放堆存储的存活指针，但实际上并非如此：
int regFree1 = 0, regFree2 = 0;
int r1, r2;
r1 = exprVectorRegister(pParse, pLeft, i, regLeft, &pL, ®Free1);
r2 = exprVectorRegister(pParse, pRight, i, regRight, &pR, ®Free2);
codeCompare(pParse, pL, pR, opx, r1, r2, addrDone, p5, isCommuted);
sqlite3ReleaseTempReg(pParse, regFree1);
sqlite3ReleaseTempReg(pParse, regFree2);
生成的比较操作会在寄存器标识符被释放以供复用之前消费它们。
对 Git 镜像的 blame 搜索发现，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, ®Free1, ®Free2);
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() 生成寄存器标识符。调用方先消费它们，然后释放。而公告却声称 sqlite3ReleaseTempReg() 先执行，exprComputeOperands() 随后访问已释放的对象。
exprComputeOperands() 的引入是为了在另一个操作数为 NULL 时避免对开销较大的子查询操作数求值。公开的表达式：
CASE WHEN (1+3) THEN (5*8) ELSE (2/0) END
包含算术运算和 CASE 表达式，但没有子查询操作数。该查询给出的理由与函数调用条件不符。
话说，用的是虚拟机
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