Use of unitialized variable in 3.32.1

(1) By Jim Borden (borrrden) on 2020-05-29 23:54:20 [link] [source]

In the analyzeOneTable function the following occurs:

for(j=0; j<pPk->nKeyCol; j++){
    k = sqlite3TableColumnToIndex(pIdx, pPk->aiColumn[j]);
    assert( k>=0 && k<pIdx->nColumn );
    sqlite3VdbeAddOp3(v, OP_Column, iIdxCur, k, regKey+j);
    VdbeComment((v, "%s.column(%d)", pIdx->zName, i));
}

Note the use of i in the last line's comment. At least on GCC this gives a warning about the variable being possibly uninitialized and I think it was the intent to use j here.

(2) By anonymous on 2020-05-30 00:35:02 in reply to 1 [link] [source]

It needs -DSQLITE_ENABLE_STAT4, but clang would still not flag it. It does look like j is intended.

The code is at analyze.c:1213

(3) By Richard Hipp (drh) on 2020-05-30 00:43:50 in reply to 1 [source]

Thanks for the report! The problem is now fixed on trunk.

Notes:

This only happens if SQLite is compiled with -DSQLITE_ENABLE_EXPLAIN_COMMENTS and with -DSQLITE_ENABLE_STAT4. Most builds of SQLite do not include either of those options.
Even when it does happen, the uninitialized integer is the input to an %d format for a string that is used as a debugging comment in the byte-code. So, in other words, the problem causes a goofy comment to appear in the comment column of the EXPLAIN output. In other words, it is utterly harmless.

It is good that the problem was found. (Thanks, borrrden!) I only include the notes above to try to prevent a CVE from being written with a scary headline: "Critical Uninitialized Variable Usage In SQLite 3.32.1" How sad that CVE politics have degenerated to the point that I feel the need to do that....