wasapi 0.25.0 makes WaveFormat parsing unsafe

RustSec issued RUSTSEC-2026-0332 on October 7, 2026, and wasapi 0.25.0 makes WaveFormat::parse unsafe; Windows developers using wasapi 0.20.0 through 0.24.x should upgrade and parse complete format blobs with the safe byte-slice API. The advisory rates this as informational unsoundness and describes an out-of-bounds read.

What changed in wasapi 0.25.0

Before the fix, WaveFormat::parse accepted a safe reference to WAVEFORMATEX. That C-compatible header is 18 bytes. If its wFormatTag was WAVE_FORMAT_EXTENSIBLE and its cbSize was at least 22, the function treated the reference as a 40-byte WAVEFORMATEXTENSIBLE and read the additional fields. A reference to the header alone does not promise that those bytes exist after it, even if the cbSize field says they should.

The advisory provides an example with cbSize: 22: calling WaveFormat::parse(&header) can read 22 bytes past the end of that header. A realistic route is copying a header from a WASAPI format pointer, for example let fmt = unsafe { *ptr };, then parsing &fmt. The copied value retains cbSize, but not the extended data that followed the original pointer. RustSec says those out-of-bounds bytes are returned as the parsed channel mask and subformat.

The fix is commit 2562db7, included in version 0.25.0. The parser now takes a *const WAVEFORMATEX and is an unsafe fn; callers must ensure the pointer is valid for size_of::<WAVEFORMATEX>() + cbSize bytes. The safer alternative, WaveFormat::parse_from_blob_bytes, has been available since 0.23.0 and checks that the byte slice is long enough for cbSize. The merged wasapi pull request #64 confirms the parser API change and identifies the blob function as the safe alternative.

Who is affected and why it matters

The affected range is >=0.20.0, <0.25.0; versions <0.20.0 are listed as unaffected, and >=0.25.0 is patched. The advisory names Windows as the affected OS. Check the version actually resolved by your application or library: a direct dependency declaration may not show the version Cargo selected for the build.

This is a soundness issue in a safe API. Code using the old method did not need an unsafe block to reach the read, so callers could not express or check the missing buffer-length guarantee at the call site. In practice, the read can expose adjacent memory values through the returned format fields. The advisory does not report a separate exploit or claim that every call triggers the read; the unsafe path depends on an extensible format header and its cbSize value.

The 0.25.0 API change makes the caller responsible for pointer validity when choosing the raw-pointer parser. That responsibility is meaningful: adding an unsafe block around a pointer to a copied 18-byte header does not restore the missing 22 bytes. Existing code that parses a standalone header should migrate to a byte slice that includes all bytes declared by the header, or retain the full WASAPI-provided buffer and pass that to the safe parser.

What to do now

For code that already has the complete format data as bytes, use the safe method in wasapi 0.25.0:

// wasapi 0.25.0; `blob` must contain the complete format data.
let format = wasapi::WaveFormat::parse_from_blob_bytes(&blob)?;

The method accepts a potentially unaligned byte slice containing a WAVEFORMATEX or WAVEFORMATEXTENSIBLE. This also matches the crate's documented approach for parsing a WASAPI device-format blob: keep the data as bytes instead of creating a reference to a header whose allocation may not include its extension. See the wasapi 0.25.0 API documentation.

Use this migration checklist:

1. Inspect your dependency tree and identify every resolved wasapi version. Update Windows builds that use a version from 0.20.0 through 0.24.x to at least 0.25.0.
2. Find calls to WaveFormat::parse. If the input is a complete format blob, switch to parse_from_blob_bytes(&blob) and handle its Result as shown above.
3. If you must use the raw-pointer parse in 0.25.0, prove at the call site that the allocation spans the 18-byte header plus the number of extension bytes in cbSize. Keep the complete WASAPI allocation alive for the call; do not pass a pointer to a copied header by itself.
4. Review wrappers around wasapi as well as direct application calls. A wrapper that still accepts only &WAVEFORMATEX cannot establish that extended bytes are present.

The key change is both a patched version and a type-level warning: callers now see that pointer parsing requires an unsafe choice. For ordinary blob input, the checked slice parser avoids putting that pointer-length proof on each caller.