---
id: "GHSA-qwgh-2vcv-g2f7"
kind: "vulnerability"
aliases: ["GHSA-qwgh-2vcv-g2f7"]
title: "block_buffer: panic corrupts inline buffer position"
severity: "medium"
cvss: null
epss: null
exploited: false
status: "open"
category: "package"
products: [{"name": "block_buffer", "fixed": ["0.12.1"], "affected": ">= 0.11.0, < 0.12.1", "ecosystem": "cargo"}]
ecosystems: ["cargo"]
tags: ["block_buffer", "cargo", "cwe-119", "package", "rust"]
not_affected_if: ["no-catch-unwind", "version-0.12.1-or-later"]
published_at: "2026-08-19T19:15:34+00:00"
first_seen_at: "2026-10-30T15:32:39+00:00"
updated_at: "2026-10-30T15:33:58+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-qwgh-2vcv-g2f7", "first_seen_at": "2026-10-30T15:32:39+00:00"}]
---

# block_buffer: panic corrupts inline buffer position

The Rust crate block_buffer can leave its internal cursor position in an invalid state if a panic occurs during block processing and is caught by the calling code. The corrupted cursor can then lead to out-of-bounds reads and writes.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- cargo:block_buffer affected >= 0.11.0, < 0.12.1 fixed 0.12.1

## How to check

- Check whether the project depends on `block_buffer` at versions `>= 0.11.0` and `< 0.12.1` with `cargo tree -i block_buffer`
- Look at `Cargo.lock` for `block_buffer` entries at a version below `0.12.1`

## Fix

- Upgrade `block_buffer` to `0.12.1`

## Timeline

- 2026-10-30T15:32:39+00:00 ghsa https://github.com/advisories/GHSA-qwgh-2vcv-g2f7

## Documents

- [advisory] Maintainer's advisory: api.github.com https://api.github.com/repos/RustCrypto/utils/security-advisories/GHSA-qwgh-2vcv-g2f7
- [advisory] Maintainer's advisory: github.com https://github.com/RustCrypto/utils/security/advisories/GHSA-qwgh-2vcv-g2f7
- [fix] Release: github.com https://github.com/RustCrypto/utils/releases/tag/block-buffer-v0.12.1

## From the sources

### Summary

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.

### Details & PoC

The following two tests fail miri:

```rust
#[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.

### Impact

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.

### Credits

The issue was discovered by GPT-5.5

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_