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()، تُحسب المعاملات قبل تحرير السجلات المؤقتة، على عكس التسلسل المذكور في النشرة؛ و
• استعلام SQL المنشور لا يحتوي على معامل استعلام فرعي، وبالتالي لا يُفعّل التحسين الذي أُدخلت من أجله exprComputeOperands().

يجب رفض سجل CVE هذا، وسأرفع نزاع CNA إلى MITRE 😉

ادعاءات النشرة

تحدد النشرة الإصدار المتأثر بأنه "SQLite 3.41" وتقدم هذا الاستعلام:

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

وتدعي أن:

1. sqlite3ReleaseTempReg() تحرر ذاكرة الكومة المرتبطة بـ regFree1؛
2. يبقى regFree1 مرجعًا معلّقًا (dangling reference)؛
3. تصل exprComputeOperands() لاحقًا إلى الذاكرة المُحرَّرة؛ و
4. تشغيل الاستعلام على نسخة مُجمَّعة مع ASan يُنتج أثرًا واضحًا لخطأ heap-use-after-free.

تحليل الكود المصدري

sqlite3ReleaseTempReg() في SQLite 3.41

تُعرّف التجميعة (amalgamation) الخاصة بـ 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. تصف النشرة 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() لم تكن موجودة

وجد بحث git 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() معرّفات السجلات، ثم يستهلكها المتصل ويحررها. في المقابل، تدعي النشرة أن 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

روابط إضافية 😁

• النشرة العامة: 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