KEVWire

Security intelligence, with context.

Response snapshot Oct 30, 2026, 17:36 UTC

Back to the wire
Permalink
VulnerabilityGHSA-qwgh-2vcv-g2f7

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: They fail on an unreachable_unchecked!() under the invariant for the pos to always be within bounds of the block.

Published Updated

At a glance

Exploited
Not known
Severity
Not scored yet
Chance of exploitation
Not estimated
Sources
1 source

What to do

GitHub lists first patched versions: block_buffer: 0.12.1. Confirm the affected range and upgrade guidance in the exact advisory.

Read GitHub-reviewed advisory GHSA-qwgh-2vcv-g2f7 (opens a new tab)

What happened

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:

Continue reading
#[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 ::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:: ::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

Affected package ranges reported by GitHub: block_buffer: >= 0.11.0, < 0.12.1

Related technology

Follow Rust crates: RSS feedAll its recordsAsk your AI assistant

Sources

  1. Primary source

    GitHub-reviewed advisory GHSA-qwgh-2vcv-g2f7 (opens a new tab)

    The public advisory supplies the description, affected package/version ranges, and any listed CVSS metric. GitHub review is not local review.

    Published Checked

  2. Primary source

    GitHub public advisory API page (opens a new tab)

    The API page supplied GHSA-qwgh-2vcv-g2f7, its actual identifiers, source dates, and structured metrics.

    Published Date not suppliedChecked

Cite this record

For factual claims, cite the primary sources above; cite KEVWire for its compilation, dates, and classifications.

APA

KEVWire. (2026, October 30). block_buffer: panic corrupts inline buffer position. https://kevwire.com/record/GHSA-qwgh-2vcv-g2f7

MLA

"block_buffer: panic corrupts inline buffer position." KEVWire, 30 Oct. 2026, kevwire.com/record/GHSA-qwgh-2vcv-g2f7.

Chicago

KEVWire. "block_buffer: panic corrupts inline buffer position." Last modified October 30, 2026. https://kevwire.com/record/GHSA-qwgh-2vcv-g2f7.

Evidence summary (plain text)

block_buffer: panic corrupts inline buffer position (Aug 19, 2026).
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:

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.
Sources:
GitHub-reviewed advisory GHSA-qwgh-2vcv-g2f7: https://github.com/advisories/GHSA-qwgh-2vcv-g2f7
GitHub public advisory API page: https://api.github.com/advisories?type=reviewed&per_page=100&sort=updated&direction=desc
Record ID: GHSA-qwgh-2vcv-g2f7.
Record origin: Ingested record.
AI evidence: Not assessed.
Known exploitation: Not assessed.
Zero-day status: Not assessed. KEV membership alone does not establish zero-day status.
About this data

This record was ingested from a data source. Retrieved: Oct 30, 2026, 17:20 UTC. Ingestion is not an independent editorial investigation.

A CISA KEV listing documents known exploitation, not necessarily a zero-day; absence from the catalog does not prove a vulnerability has never been exploited.

Technology tags indicate possible relevance, not verified exposure. Confirm the affected product, version, and configuration against your own inventory; KEVWire does not scan your systems.

A personal reading checklist on this device, not verified remediation.

Record JSON

Your account

Email alerts

Email alerts are coming as part of KEVWire Premium: join the waitlist. To follow your stack today, use its RSS feed, which honors your filters, or connect an AI agent through the API.

Suggest an improvement

Ideas, missing sources, corrections, and bugs are all welcome. No account needed. Suggestions are reviewed by a person before anything changes.

Record details

Record detail