GStreamer WavPack Decoder CVE-2026-53705: Overview of an Integer Overflow Leading to Heap Corruption

Introduction

A single integer overflow in a buffer size calculation inside GStreamer's WavPack decoder can turn a malicious audio file into a vehicle for heap corruption and potential code execution, and it affects every major Linux distribution that ships GNOME. The overflow happens on 64-bit systems too, despite the common assumption that they are inherently protected from integer overflow exploits. GNOME's automatic media indexer can also trigger it without any explicit user interaction.

GStreamer is a pipeline-based multimedia framework written in C. It was first created in 1999 and is now one of the most widely deployed media processing libraries in the open-source ecosystem. It is embedded by default in GNOME desktop environments, the WebKit browser engine, and numerous media applications across Linux, Windows, macOS, and mobile platforms. Its plugin architecture (gst-plugins-good, gst-plugins-bad, gst-plugins-ugly) provides the codec support that makes it the default media handler for distributions including Fedora, Ubuntu, and Debian.

Technical information

Root cause: 32-bit integer overflow in buffer allocation

CVE-2026-53705 is classified as CWE-190 (Integer Overflow or Wraparound) and carries a CVSS score of 7.6. The vulnerability lives in the function gst_wavpack_dec_handle_frame() within the wavpackdec element of gst-plugins-good.

When decoding a WavPack audio file, the function allocates a buffer for the decoded audio samples. The original code did this with:

dec_data = g_malloc(4 * wph.block_samples * dec->channels);

Every operand in the expression 4 * wph.block_samples * dec->channels is a 32-bit integer. C performs the multiplication in the type of the operands, so the entire calculation happens in 32-bit arithmetic. Only after the multiplication completes is the result widened to size_t (the argument type of g_malloc()).

If an attacker crafts a WavPack file with block_samples and channels values chosen so that the product 4 * block_samples * channels exceeds 2^32, the multiplication wraps around to a very small value. Values that should produce a legitimate allocation of several gigabytes produce an allocation of just a few bytes instead. The WavPack library then writes the full volume of decoded audio samples into this undersized buffer and overwrites heap memory far beyond the allocation boundary.

Why 64-bit systems are not protected

A common defensive assumption is that 64-bit systems are immune to this class of vulnerability because size_t is 64 bits wide. Here that assumption fails. The overflow occurs entirely within 32-bit integer arithmetic before the result is promoted to size_t for the g_malloc() call. The already-wrapped small value is zero-extended to 64 bits, which produces a valid but dangerously small allocation on 64-bit systems, exactly as it does on 32-bit systems.

Contributing factors

The GStreamer security advisory notes two additional issues that compound the primary overflow:

1. Several loop counters and size variables (i, j, num_samples, unpacked_size) were declared as gint or int32_t, which introduced implicit 32-bit truncation in later arithmetic.
2. In error paths, the code called gst_audio_decoder_finish_frame() before unmapping the input buffer, so it could access a buffer that had already been invalidated.

Attack flow

An attacker would exploit this vulnerability in the following sequence:

1. The attacker constructs a malicious .wv file whose WavPack header contains block_samples and channels values chosen so that 4 * block_samples * channels overflows a 32-bit integer to a small value (e.g., 16 bytes).

2. The attacker delivers the file to the target through one of several vectors:

   • Direct file sharing (email attachment, download link, file share)
   • Embedding in a web page served to a WebKit-based browser (which uses GStreamer for media playback)
   • Placing the file in a location that GNOME's localsearch (tracker-miners) will automatically index

3. GStreamer processes the file, and gst_wavpack_dec_handle_frame() allocates a tiny heap buffer based on the overflowed size calculation.

4. The WavPack library writes the full decoded audio data into the undersized buffer and corrupts adjacent heap metadata and objects.

5. Depending on the heap layout, the attacker achieves either a denial of service (crash) or, with careful heap grooming, arbitrary code execution.

GNOME's localsearch engine (formerly tracker-miners) automatically indexes media files in the user's home directory and extracts their metadata with GStreamer. Downloading a malicious WavPack file to the home directory, or having another application place one there, can therefore trigger the vulnerability without the user ever opening the file. In the oss-sec mailing list discussion, Solar Designer specifically highlighted this automatic processing path as a concern.

Input validation bypass

The input framing validation in the original code also contained an overflow-prone comparison:

if (map.size < wph.ckSize + 4 * 1 + 4)

If wph.ckSize is attacker-controlled and large, the addition on the right-hand side can itself overflow, and the validation check passes when it should fail. Malformed input can then reach the vulnerable buffer allocation code.

Patch information

The vulnerability is patched in GitLab merge request !11797, authored by Sebastian Dröge and merged on June 5, 2026. The fix ships in gst-plugins-good 1.28.4, released on June 12, 2026, as documented in GStreamer Security Advisory SA-2026-0035. All the changes are in a single file, subprojects/gst-plugins-good/ext/wavpack/gstwavpackdec.c, split across four focused commits.

Commit 1: Safe output buffer size calculation (318f72af)

This is the core of the fix. The original vulnerable allocation:

dec_data = g_malloc(4 * wph.block_samples * dec->channels);

is replaced with GLib's overflow-safe g_size_checked_mul(). The new code performs the multiplication in two explicit steps and jumps to the invalid_header error path if either step overflows:

gsize dec_data_size;
/* ... */
dec_data_size = 4;
if (!g_size_checked_mul(&dec_data_size, dec_data_size, wph.block_samples) ||
    !g_size_checked_mul(&dec_data_size, dec_data_size, dec->channels))
  goto invalid_header;
dec_data = g_malloc(dec_data_size);

With the new gsize dec_data_size variable and the two chained checked multiplications, the code catches any crafted WavPack header that would push the product 4 * block_samples * channels past the addressable range, and it does so before any allocation occurs.

Commit 2: Correct variable types (8472adc6)

Several loop counters and size variables (i, j, num_samples, unpacked_size) were originally declared as gint or int32_t. The patch promotes them to gsize (the platform-native unsigned size type) and changes decoded from int32_t to uint32_t. This removes any remaining implicit 32-bit truncation in later arithmetic.

Commit 3: Safe input buffer size check (f2313c0b)

The overflow-prone input validation:

if (map.size < wph.ckSize + 4 * 1 + 4)

is rearranged algebraically so the constants are subtracted from the known-safe map.size instead:

if (map.size - 4 * 1 - 4 < wph.ckSize)

Moving constant additions to the left side as subtractions is a classic defense, and it avoids overflow on the comparison's right-hand operand entirely.

Commit 4: Fix buffer unmap ordering in error paths (e92726ba)

The final commit moves the gst_buffer_unmap(buf, &map) call to immediately after WavpackUnpackSamples() returns, instead of at the end of the function. Previously, if a decode error occurred, the code path called gst_audio_decoder_finish_frame() before unmapping the input buffer and could access a buffer that had already been invalidated. The commit adds a local guint64 offset variable that saves the buffer offset before unmapping, so the offset can still be copied to the output buffer later.

Together the four commits give defense in depth: one removes the primary integer overflow, and the other three harden the surrounding arithmetic with correct types, make input validation overflow-safe, and fix resource handling in error paths.

Affected systems and versions

The vulnerability affects the wavpackdec element in gst-plugins-good versions prior to 1.28.4. The fix is included in gst-plugins-good 1.28.4, released on June 12, 2026.

Both 32-bit and 64-bit systems running any affected version are vulnerable, because the integer overflow occurs in 32-bit arithmetic regardless of the platform's native word size.

Systems at elevated risk include:

• Any Linux distribution shipping GNOME with GStreamer (Fedora, Ubuntu, Debian, and derivatives)
• Environments using WebKit-based browsers, which rely on GStreamer for media playback
• Systems running GNOME versions prior to 46, which lack sandbox isolation for the localsearch media indexer
• Embedded systems and media processing pipelines using GStreamer for audio decoding

Debian (DSA 6318-1) and Ubuntu (USN-8317-1) have issued distribution-specific advisories for earlier gst-plugins-good CVEs. Advisories that specifically cover CVE-2026-53705 may still be forthcoming from those distributions.

Vendor security history

GStreamer has a substantial and growing history of security vulnerabilities, and integer overflow and memory corruption flaws recur across the codebase. The GStreamer Security Center documents the following approximate advisory counts by year:

The first half of 2026 alone produced 42 advisories, a significant acceleration. CWE-190 (Integer Overflow) has appeared repeatedly across GStreamer components, including the WAV, RIFF, AVI, H.266, JPEG 2000, AV1, and now WavPack parsers. Notable related CVEs include:

• CVE-2026-3083 (ZDI-26-166): Out-of-bounds write in rtpqdm2depay, CVSS 8.8, disclosed via the Zero Day Initiative
• CVE-2026-3084: H.266 codec parser integer overflow leading to OOB write
• CVE-2026-1940: WAV buffer overflow
• CVE-2026-5056: MOV/MP4 integer overflow and OOB

The same vulnerability class keeps turning up in many different parsers, which indicates a systemic issue in how the GStreamer codebase performs buffer size calculations, as opposed to isolated mistakes in individual components. The volume and pattern suggest that the codebase would benefit from a systematic audit of every buffer size calculation using safe integer arithmetic, in addition to point fixes for individually reported CVEs.

References

• NVD: CVE-2026-53705
• GStreamer Security Advisory SA-2026-0035
• GitLab Merge Request !11797 (Patch)
• Red Hat CVE Page: CVE-2026-53705
• Red Hat Bugzilla: Bug 2487615
• oss-sec: Re: 10+ CVEs in GStreamer
• CWE-190: Integer Overflow or Wraparound
• GStreamer Security Center
• GStreamer (Wikipedia)
• Debian Security Advisory DSA 6318-1 (gst-plugins-good1.0)
• Ubuntu Security Notice USN-8317-1
• ZDI-26-166: GStreamer rtpqdm2depay OOB Write
• GitHub: GStreamer/gst-plugins-good
• CISA Known Exploited Vulnerabilities Catalog