GHSA-GGXF-9F6J-W742: Use-After-Free in Diesel SQLite Deserialization

The diesel crate is a widely adopted Object-Relational Mapping (ORM) and query builder for Rust. Its SQLite backend provides interfaces to connect to, query, and manage SQLite databases, relying on Foreign Function Interface (FFI) bindings to communicate with the native libsqlite3 C library.

To facilitate database loading from memory, Diesel provides the API SqliteConnection::deserialize_readonly_database_from_buffer and its wrapper SqliteConnection::deserialize_readonly_database. These functions allow applications to deserialize a SQLite database directly from an in-memory byte slice (&[u8]). This feature exposes a direct attack surface if the underlying database bytes can be supplied by an external or untrusted source.

The core vulnerability is a Use-After-Free (UAF) condition classified under CWE-416. Because of missing lifetime constraints in the safe Rust wrapper signature, the memory safety guarantees of Rust were bypassed, allowing the backing buffer to be deallocated while the database connection retained active references to the deallocated heap memory.

The native SQLite C library implements a memory-deserialization feature via sqlite3_deserialize. When configured to operate on a read-only database buffer, the engine avoids making an internal copy of the data. Instead, it maintains a raw pointer pointing directly to the memory address of the provided buffer, assuming that this memory block will remain allocated and static for the duration of the connection's lifetime.

In Diesel's pre-patch implementation, the safe Rust wrapper accepted the input buffer as data: &[u8]. Because this slice's lifetime was not bound to the SqliteConnection struct, Rust's borrow checker allowed the caller to drop or reallocate the backing buffer immediately after the deserialization function returned, even while the connection object remained alive.

Once the backing buffer is dropped, the memory is reclaimed by the allocator. When the application subsequently executes a query on the open connection, the underlying libsqlite3 library dereferences the cached raw pointer to read database pages. This results in an expired pointer dereference (CWE-825) and triggers a heap-use-after-free condition.

The pre-patch implementation of the deserialization function lacked the safety invariants required to prevent the backing buffer from being dropped prematurely. The signature and implementation were defined as follows:

// Pre-patch vulnerable function signature:
pub fn deserialize_readonly_database_from_buffer(&mut self, data: &[u8]) -> QueryResult<()> {
    self.raw_connection.deserialize(data)
}

To resolve this soundness issue, the developers modified the SqliteConnection struct to take ownership of the buffer data. This ensures that the buffer is kept alive as long as the connection itself. The patch introduces a serialized_data: Vec<u8> field to the connection struct and clones the slice:

// Post-patch implementation in diesel/src/sqlite/connection/mod.rs
pub struct SqliteConnection {
    // Fields omitted for brevity
    metadata_lookup: (),
    instrumentation: DynInstrumentation,
    // This field must come after the RawConnection to ensure correct drop order
    serialized_data: Vec<u8>,
}
 
impl SqliteConnection {
    pub fn deserialize_readonly_database_from_buffer(&mut self, data: &[u8]) -> QueryResult<()> {
        // Copy the buffer to make sure it lives as long as the connection
        self.serialized_data = data.to_vec();
        self.raw_connection.deserialize(&self.serialized_data)
    }
}

In Rust, struct fields are dropped in declaration order (top-to-bottom). Because serialized_data is declared after raw_connection, the connection is closed first during a drop sequence, ensuring that libsqlite3 releases its reference to the memory before the Vec<u8> buffer is deallocated. While this fix introduces an allocation overhead due to cloning the database buffer, it completely remediates the vulnerability without breaking the public API signature.

Exploiting this vulnerability requires a target application that loads SQLite databases dynamically using the vulnerable Diesel functions and subsequently processes queries on the connection after the source buffer has been deallocated.

An attacker can supply a malicious or specifically crafted SQLite database to an endpoint. Once the server loads the database using deserialize_readonly_database_from_buffer and releases the original upload buffer, the memory is marked as free. When the server then executes a database query, the engine reads from the freed heap space.

If the deallocated memory is repurposed by other threads, the application may read corrupted data, causing a segmentation fault. If an attacker can perform heap grooming to fill the deallocated memory block with attacker-controlled data, it is theoretically possible to manipulate SQLite's internal data structures, leading to unauthorized state modification.

The impact of this vulnerability is categorized as Moderate with a CVSS v4.0 base score of 5.3. The severity is constrained because the vulnerability requires a specific sequence of API calls and buffer management in the calling application to manifest.

The primary consequences are system instability, unexpected application behavior, and process crashes due to memory corruption. In multi-threaded environments, reading from freed memory can leak sensitive details of other sessions if those sessions occupy the recycled heap segments.

Because this is a library-level memory safety flaw rather than a protocol or application-level exposure, the direct risk is highly dependent on how the parent application implements and handles the database deserialization routines.

The primary remediation strategy is to upgrade the diesel crate to version 2.3.10 or newer, which contains the official patch. No code modifications are required by callers, as the fix maintains backwards compatibility.

# Cargo.toml
diesel = { version = "2.3.10", features = ["sqlite"] }

If upgrading is not immediately possible, applications must ensure that the lifetime of the input buffer exceeds that of the connection. This can be accomplished by structuring the code so the buffer is stored in a scope that outlasts the SqliteConnection:

// Workaround: Manually managing the lifetime
fn process_db(data: Vec<u8>) {
    let mut conn = SqliteConnection::establish(":memory:").unwrap();
    // Keep 'data' alive for the duration of the connection's usage
    conn.deserialize_readonly_database_from_buffer(&data).unwrap();
    execute_queries(&mut conn);
    std::mem::drop(conn); // Explicitly drop connection before the buffer
    std::mem::drop(data);
}

To detect this issue during development, compile tests using AddressSanitizer (ASAN) and verify that dropping the input buffer before executing a query triggers a diagnostic failure.