crates.io · block_buffer
block_buffer: panic corrupts inline buffer position
A caught panic may leave the cursor position of EagerBuffer or ReadBuffer in a corrupted state; this in turn allows out-of-bounds reads/writes.
The following two tests fail miri:
#[cfg(miri)]
#[test]
fn eager_digest_blocks_panic_corrupts_inline_position() {
// `EagerBuffer` stores its cursor in the last byte of the internal block.
// When `digest_blocks` completes a previously partial block, it overwrites
// that byte with input data before invoking the caller-provided `compress`
// callback. If the callback panics, safe code can catch the panic and keep
// using the buffer while its cursor byte no longer satisfies the internal
// `pos < block_size` invariant. Under Miri this `get_pos` call reaches the
// `unreachable_unchecked` used for the assumed-valid cursor.
let mut buf = EagerBuffer::<U4>::new(&[1, 2]);
let _ = std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| {
buf.digest_blocks(&[3, 0xff], |_| panic!("simulated compression failure"));
}));
let _ = buf.get_pos();
}
#[cfg(miri)]
#[test]
fn read_buffer_generator_panic_corrupts_inline_position() {
// `ReadBuffer` stores its cursor in `buffer[0]`, but `write_block` gives
// `gen_block` mutable access to the whole internal block before restoring
// `buffer[0]` to a valid cursor. If `gen_block` writes an arbitrary first
// byte and panics, safe code can catch the panic and later observe an
// invalid cursor. Under Miri this `get_pos` call reaches the
// `unreachable_unchecked` used for the assumed-valid cursor.
let mut buf = ReadBuffer::<U4>::default();
let _ = std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| {
buf.write_block(
1,
|block| {
block[0] = 0xff;
panic!("simulated block generation failure");
},
|_| {},
);
}));
let _ = buf.get_pos();
}
They fail on an unreachable_unchecked!() under the invariant for the pos to always be within bounds of the block.
While the byte that overwrites pos may come from untrusted input and is therefore attacker-controlled, this still relies on the surrounding code catching the panic and carrying on, which should be uncommon in practice.
For this to be exploitable, the attacker also needs a way to trigger a panic here; I have not investigated how feasible that is.
The issue was discovered by GPT-5.5
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.