CVE-2026-51302: तकनीकी असंगतियाँ

क्लिकबेट रिपो नाम के लिए खेद है, लेकिन यह CVE पूरी तरह से LLM-हैलुसिनेटेड बकवास है, सचमुच दुख की बात है कि एक CNA ने इसे स्वीकार कर लिया जबकि दावे कितने असंगत हैं 💔

निष्कर्ष

CVE-2026-51302 असली नहीं है 😱

प्रकाशित SQL किसी भी SQLite 3.41 रिलीज़ में AddressSanitizer के अंतर्गत use-after-free को रिप्रोड्यूस नहीं करता। अधिक महत्वपूर्ण बात यह है कि बताया गया मूल कारण प्रभावित स्रोत के साथ पूरी तरह से असंगत है:

• exprComputeOperands() SQLite 3.41.0, 3.41.1 या 3.41.2 में मौजूद नहीं है;
• वह फ़ंक्शन 30 जून 2025 को पेश किया गया था, SQLite 3.41 के दो साल से अधिक समय बाद;
• regFree1 एक पूर्णांक वर्चुअल-मशीन रजिस्टर पहचानकर्ता है, हीप स्टोरेज का पॉइंटर नहीं;
• sqlite3ReleaseTempReg() एक रजिस्टर को पुन: उपयोग के लिए उपलब्ध कराता है और regFree1 में कोई डैंगलिंग C पॉइंटर नहीं छोड़ता;
• जिन स्रोत संस्करणों में exprComputeOperands() होता है, वहाँ अस्थायी रजिस्टर रिलीज़ होने से पहले ऑपरेंड की गणना की जाती है, जो एडवाइज़री में बताए गए क्रम के विपरीत है; और
• प्रकाशित SQL में कोई सबक्वेरी ऑपरेंड नहीं है और इसलिए यह उस ऑप्टिमाइज़ेशन को लागू नहीं करता जिसके लिए exprComputeOperands() को पेश किया गया था।

यह CVE रिकॉर्ड अस्वीकार किया जाना चाहिए और मैं MITRE के साथ एक CNA विवाद दर्ज करूँगा 😉

एडवाइज़री का दावा

एडवाइज़री प्रभावित संस्करण को "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 ट्रेस उत्पन्न होता है।

स्रोत विश्लेषण

SQLite 3.41 में sqlite3ReleaseTempReg()

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 मिरर की ब्लेम खोज में पाया गया कि 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