Predator could not provide any possible suspects.
Assigning to concern owner from CL --
https://chromium.googlesource.com/chromium/src/+log/12d428d5d4f63b4e39f7eb8aacc66b8444419982..18e1135f8cf11cd525d95755de40f00afa979e32?pretty=fuller&n=10000

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/0270407c0555655d204235d1fa39c86d453cb809

@michaeln -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

It repros easily, here's the repro as a TEST() fixture. Each 'sqlite3_step' gobbles up more memory, this must have to do with the zeroblobs() in the fuzzed_sql.

#include "third_party/sqlite/sqlite3.h"

TEST(FuzzerTest, sqlite3_prepare_v2_fuzzer) {

  sqlite3* db;
  int return_code = sqlite3_open_v2(
      "db.db",
      &db,
      SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE | SQLITE_OPEN_MEMORY, 0);

  if (SQLITE_OK != return_code)
    return;

  const char fuzzed_sql[] = R"(SELECT""in(?,zeroblob(49E6),65543)in(?,zeroblob(17E6),31086)``WHERE``|``IS``|``|``|``|``|``|``|``|``<``<``)";

  sqlite3_stmt* statement = NULL;
  int result = sqlite3_prepare_v2(db, fuzzed_sql,
                                  strlen(fuzzed_sql), &statement, NULL);
  if (result == SQLITE_OK) {
    // Use selector value to randomize number of iterations.
    for (int i = 0; i < 255; i++) {
      if (sqlite3_step(statement) != SQLITE_ROW)
        break;
    }

    sqlite3_finalize(statement);
  }

  sqlite3_close(db);
}

All it takes is one call to sqlite3_step() and gigabytes are consumed, in increments, and then the function returns SQLITE_ROW.

sqlite3_prepare_v2(db, fuzzed_sql,
                   strlen(fuzzed_sql), &statement, NULL);
sqlite3_step(statement);
sqlite3_finalize(statement);
sqlite3_close(db);

The memory is freed up in finalize().

SELECT ZEROBLOB(1000000000), ZEROBLOB(1000000000)

Will consume ~2G. The limit for an indiviual blob is 1000000000, which is also the max size of a row in the db, however apparently this limit is not applied to a resultant row.

/*
** The maximum length of a TEXT or BLOB in bytes.   This also
** limits the size of a row in a table or index.
**
** The hard limit is the ability of a 32-bit signed integer
** to count the size: 2^31-1 or 2147483647.
*/
#ifndef SQLITE_MAX_LENGTH
# define SQLITE_MAX_LENGTH 1000000000
#endif

I'm not sure this is much different than allocating large ArrayBuffers from javascript?

I don't think this is a P1, but if i'm wrong please push back.

It might make sense to have a SQLITE_MAX_RESULT_LENGTH and to have sqlite3_step() fail with SQLITE_TOOBIG if the sum of the values in the resulting row exceeds that length in bytes. I don't think there is anything like that atm, sqliteLimit.h defines these sort of limits. I think that feature would require modifications to sqlite.

For more information, please see https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md.

The link referenced in the description is no longer valid.

ClusterFuzz testcase 5119659933433856 is flaky and no longer crashes, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.