Heap Buffer Overflow in SQLite sessionReadRecord During sessionfuzz Execution

Session Extension Buffer Overflow via Invalid iNext Offset in sessionReadRecord

Root Cause: Insufficient Bounds Checks for Integer/Float Value Deserialization

The core issue is a heap-buffer-overflow vulnerability triggered during deserialization of SQLITE_INTEGER or SQLITE_FLOAT values in the sessionReadRecord function of SQLite’s session extension. This occurs when processing a malformed changeset (a binary record of database changes) using the sessionfuzz utility. The vulnerability stems from a missing bounds check on the pIn->iNext offset before attempting to read 8-byte integer or floating-point values from the input buffer (pIn->aData). When pIn->iNext exceeds the valid range of the buffer (as defined by pIn->nData), the code accesses memory outside the allocated buffer, leading to undefined behavior, crashes, or potential exploitation.

The specific code path involves:

1. sessionReadRecord: A function responsible for deserializing a single database record from a changeset.
2. sessionGetI64: A helper function that reads an 8-byte integer from the buffer at offset pIn->iNext.
3. Missing validation of pIn->iNext before accessing aVal = &pIn->aData[pIn->iNext] for integer/float types.

The AddressSanitizer (ASAN) report confirms that pIn->iNext is 0x25 (37 bytes) while pIn->nData is 0x26 (38 bytes), meaning the code attempts to read an 8-byte value starting at byte 37 in a 38-byte buffer. This results in a 1-byte overflow (reading up to byte 44). The vulnerability is exploitable when SQLite processes a crafted changeset that declares a column as SQLITE_INTEGER or SQLITE_FLOAT but provides insufficient data for the 8-byte value.

Failure Modes: Corrupted Input Handling and Deserialization Logic Gaps

1. Invalid eType Enumeration or Desynchronized Input Parsing

The eType variable (representing the data type of the current column) is derived earlier in sessionReadRecord by reading a byte from the input buffer. If this byte is corrupted or manipulated (e.g., due to a separate parsing error), eType could incorrectly indicate an integer or float type even when the input buffer lacks sufficient bytes. This desynchronizes the parser, causing it to attempt reads beyond valid boundaries.

2. Absence of Pre-Read Bounds Checks for Fixed-Size Data Types

While variable-length types (TEXT/BLOB) include checks to ensure nByte (the value’s length) does not exceed pIn->nData - pIn->iNext, the integer/float handling path lacks equivalent validation. The code assumes that eType validation alone ensures the buffer contains 8 bytes. This assumption fails if:

• The changeset is truncated or malformed.
• A prior parsing error corrupts pIn->iNext.
• The eType value is invalid but not properly handled.

3. Session Extension’s Input Validation Incompleteness

The session extension’s changeset parser prioritizes performance over exhaustive input validation. While it checks for structural integrity in many cases, certain edge cases (e.g., mismatched data type declarations and buffer lengths) are not fully validated. This creates a scenario where a malicious or malformed changeset can bypass sanity checks and trigger memory corruption.

Resolution: Bounds Check Enforcement and Input Sanitization Strategies

1. Immediate Patch: Add Pre-Read Bounds Check for Fixed-Size Values

The fix involves adding a bounds check before deserializing integer/float values to ensure pIn->iNext + 8 <= pIn->nData. The patch modifies the code as follows:

if( eType==SQLITE_INTEGER || eType==SQLITE_FLOAT ){
  if( pIn->iNext + sizeof(sqlite3_int64) > pIn->nData ){ // NEW CHECK
    rc = SQLITE_CORRUPT_BKPT;
  } else {
    sqlite3_int64 v = sessionGetI64(aVal);
    // ... existing code ...
  }
}

This check ensures that reading 8 bytes from aVal will not exceed the buffer’s allocated size. If the check fails, the parser returns SQLITE_CORRUPT_BKPT, marking the changeset as invalid.

2. Comprehensive Input Validation in sessionReadRecord

Beyond the immediate patch, review all data type handling paths in sessionReadRecord for similar issues:

• Validate eType early: Ensure eType corresponds to a valid SQLite data type before proceeding.
• Centralize bounds checking: Refactor common bounds-checking logic into helper functions to avoid code duplication.
• Audit variable-length data handling: Verify that all code paths incrementing pIn->iNext (e.g., for varints, strings, blobs) include overflow checks.

3. Fuzzing and Sanitizer-Enabled Testing

The vulnerability was discovered via fuzzing with AddressSanitizer. To prevent regressions:

• Integrate continuous fuzzing: Use tools like libFuzzer or AFL++ with corpus sets covering edge cases (e.g., minimal changesets, malformed headers).
• Enable runtime sanitizers: Build SQLite with -fsanitize=address,undefined in CI pipelines to catch memory errors and undefined behavior.
• Extend sessionfuzz tests: Add test cases that explicitly validate bounds checks for all data types.

4. Handling CVEs and Public Disclosure

While SQLite’s policy is not to participate in the CVE system, users and downstream projects should:

• Monitor official channels: Track SQLite’s fossil repository and mailing lists for security updates.
• Apply patches promptly: The fix is available in commit 0e4e7a05c4204b47. Merge this into custom builds or wait for official amalgamation updates.
• Consider independent CVE assignment: If organizational policies require CVEs, reporters can request one via MITRE or CVE Numbering Authorities (CNAs).

Developer Action Plan: Mitigation and Defense-in-Depth

1. Apply the Patch

   • For custom SQLite builds: Backport the fix to the sessionReadRecord function.
   • For official amalgamation builds: Update to a version including commit 0e4e7a05c4204b47.

2. Harden the Session Extension

   • Validate eType exhaustively: Before processing any value, ensure eType is within the set of valid SQLite data types.
   • Add redundancy checks: After incrementing pIn->iNext, assert that it does not exceed pIn->nData.

3. Enhance Fuzzing Coverage

   • Seed corpus expansion: Include test cases with:
     • Extremely short input buffers.
     • Invalid eType bytes.
     • Mismatched column counts and data types.
   • Differential fuzzing: Compare the behavior of patched and unpatched builds to detect regressions.

4. Deploy Runtime Protections

   • Enable SQLITE_DEBUG: Use SQLite’s internal sanity checks (sqlite3_memdebug_pending(), etc.) in debug builds.
   • Leverage hardware features: On supported platforms, enable memory tagging (ARM MTE, x86 CET) to detect out-of-bounds accesses.

End-User Recommendations: Safe Handling of Changesets

1. Validate Changesets Before Application

   • Use sqlite3changeset_validate() to check structural integrity before applying changesets from untrusted sources.

2. Isolate Session Extension Usage

   • Restrict use of sqlite3session APIs to trusted inputs or within sandboxed environments.

3. Monitor for Updates

   • Subscribe to SQLite’s RSS feed or fossil repository notifications for real-time security updates.

This comprehensive approach addresses not only the immediate buffer overflow but also systemic issues in input validation and testing practices, reducing the likelihood of similar vulnerabilities in the future.