Listen to this Post
The vulnerability stems from improper handling of MySQL temporal column data (DATE, TIME, DATETIME, TIMESTAMP) within the `diesel-async` crate. The core issue lies in the `MysqlRow::get` method (diesel-async/src/mysql/row.rs, lines 65-103).
When reading a temporal value, the method constructs a `MysqlTime` structure from the parsed mysql_async::Value. This structure is `[repr(C)]` and contains 3 bytes of padding after the `bool neg` field on Linux x86_64 (offsets 0x21..0x23). The method then creates a byte buffer from the raw memory of this `MysqlTime` instance:
let ptr = &date as const MysqlTime as const u8; let slice = std::slice::from_raw_parts(ptr, std::mem::size_of::<MysqlTime>()); slice.to_vec()
Because the `MysqlTime` is instantiated normally (MysqlTime::new()), the padding bytes remain uninitialized. The subsequent `to_vec()` call copies these uninitialized bytes into a Vec<u8>, which becomes the backing buffer for a MysqlValue. This buffer is then exposed as a `&
` slice via the safe `MysqlValue::as_bytes()` method. Reading this slice in safe Rust code constitutes undefined behavior (UB), as it accesses uninitialized memory. This issue is both a soundness bug in the crate's safe API and a potential information-disclosure vector, as the leaked bytes can contain stale heap or stack data from previous operations. The PoC provided in the advisory demonstrates this by creating a row with a `DATE` value, extracting its bytes via <code>as_bytes()</code>, and then summing them. Running the code under Miri triggers a UB error: <code>error: Undefined Behavior: reading memory at alloc844[0x21..0x22], but memory is uninitialized</code>. <h2 style="color: blue;">dailycve form:</h2> Platform: `diesel-async` Version: `<=0.8.0` Vulnerability :<code>Uninitialized stack padding</code> Severity: `Low` date: `2026-04-30` <h2 style="color: blue;">Prediction: `2026-07-30`</h2> <h2 style="color: blue;">Analytics under heading What Undercode Say:</h2> Show potential patterns via `cargo auditable` and runtime detection with Miri: [bash] Install cargo audit and rust-src for Miri cargo install cargo-audit rustup component add rust-src Check for vulnerable dependency cargo audit | grep -i "diesel-async" Detect UB with Miri cargo +nightly miri test Dump alloc ranges for inspection (conceptual) echo "Check: offset 0x21..0x22 (3 byte padding after bool neg)"
// Analytical snippet to inspect padding (illustrative)
let value = field.value().unwrap();
let bytes = value.as_bytes();
if bytes.len() > 0x23 {
println!("Padding bytes: {:?}",&bytes[0x21..0x23]);
}
Exploit:
- Trigger: Query any MySQL temporal column (
DATE,TIME,DATETIME,TIMESTAMP) usingAsyncMysqlConnection, then call `MysqlValue::as_bytes()` on the returned field. - Ub Manifestation: Access the resulting byte slice anywhere in safe code (e.g., iteration, printing, copying) – Miri will flag UB.
- Info Leak: Uninitialized padding exposes stale stack/heap leftovers from prior allocations in the same process.
Protection from this CVE
- Immediate Fix: Patch `diesel-async` to use `MaybeUninit::
::zeroed()` + ptr::copy_nonoverlapping, mirroring the pattern in the `diesel` crate (diesel/src/mysql/value.rs). - Alternative Fix: Serialize bytes directly without constructing a `MysqlTime` temporary.
- Workaround: Avoid calling `MysqlValue::as_bytes()` on temporal columns, or avoid using `AsyncMysqlConnection` for such queries until patched.
- Upgrade Path: Update to patched version once released (v0.8.1 or later).
Impact
- Scope: All users of `AsyncMysqlConnection` whose queries return a
DATE,TIME,DATETIME, orTIMESTAMP. - Severity: Low – The leak is limited to padding bytes (3 bytes per temporal field), but constitutes a soundness violation in safe Rust.
- Consequence: Undefined Behavior in safe code, potential disclosure of sensitive memory contents, and risk of program miscompilation.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
