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, affecting every major Linux distribution that ships GNOME. What makes this particular flaw worth paying attention to is that it bypasses the common assumption that 64-bit systems are inherently protected from integer overflow exploits, and that GNOME's automatic media indexer can trigger it without any explicit user interaction.

GStreamer is a pipeline-based multimedia framework written in C, originally created in 1999, and 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 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 needs to allocate a buffer for the decoded audio samples. The original code performed this allocation 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. The C language performs the multiplication in the type of the operands, meaning 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 where block_samples and channels are chosen so that the product 4 * block_samples * channels exceeds 2^32, the multiplication wraps around to a very small value. For example, values that would produce a legitimate allocation of several gigabytes instead produce an allocation of just a few bytes. The WavPack library then writes the full volume of decoded audio samples into this undersized buffer, overwriting 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. In this case, 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 simply zero-extended to 64 bits, producing a valid but dangerously small allocation on 64-bit systems just as it does on 32-bit systems.

Contributing Factors

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

1. Incorrect variable types: Several loop counters and size variables (i, j, num_samples, unpacked_size) were declared as gint or int32_t, introducing implicit 32-bit truncation in later arithmetic.
2. Improper buffer unmap ordering: In error paths, the code called gst_audio_decoder_finish_frame() before unmapping the input buffer, potentially accessing an already-invalidated buffer.

Attack Flow

An attacker would exploit this vulnerability through the following sequence:

1. Craft a malicious WavPack file: The attacker constructs a .wv file with a WavPack header containing 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. Deliver the file to the target: Multiple delivery vectors are available:

   • 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. Trigger decoding: When GStreamer processes the file, gst_wavpack_dec_handle_frame() allocates a tiny heap buffer based on the overflowed size calculation.

4. Heap corruption: The WavPack library writes the full decoded audio data into the undersized buffer, corrupting adjacent heap metadata and objects.

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

The localsearch attack path is particularly notable. GNOME's localsearch engine (formerly tracker-miners) automatically indexes media files in the user's home directory and extracts metadata using GStreamer. This means that merely downloading a malicious WavPack file to the home directory, or having one placed there by another application, can trigger the vulnerability without any explicit user action to open it. The oss-sec mailing list discussion by 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 right-hand addition can itself overflow, causing the validation check to pass when it should fail. This allows malformed input to reach the vulnerable buffer allocation code.

Patch Information

The vulnerability is patched via 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 changes land 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(), performing the multiplication in two explicit steps and aborting into the invalid_header error path if either 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);

By introducing the gsize dec_data_size variable and chaining the two checked multiplications, any crafted WavPack header that would cause the product 4 * block_samples * channels to exceed the addressable range is caught 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 eliminates any remaining implicit 32-bit truncation during later arithmetic.

Commit 3: Safe input buffer size check (f2313c0b)

The overflow-prone input validation:

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

is algebraically rearranged to subtract the constants from the known-safe map.size instead:

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

This is a classic defense: moving constant additions to the left side as subtractions 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 would call gst_audio_decoder_finish_frame() before unmapping the input buffer, potentially accessing an already-invalidated buffer. A local guint64 offset variable is introduced to preserve the buffer offset before unmapping, so it can still be copied to the output buffer later.

Taken together, the four commits form a defense-in-depth approach: the primary integer overflow vector is eliminated, surrounding arithmetic is hardened with correct types, input validation is made overflow-safe, and resource management in error paths is made robust.

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, as 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

Distribution-specific advisories for earlier gst-plugins-good CVEs have been issued by Debian (DSA 6318-1) and Ubuntu (USN-8317-1), but advisories specifically covering CVE-2026-53705 may still be forthcoming for those distributions.

Vendor Security History

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

The 42 advisories in the first half of 2026 alone represent a significant acceleration. CWE-190 (Integer Overflow) has appeared repeatedly across multiple GStreamer components, including 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 recurrence of the same vulnerability class across so many different parsers indicates a systemic issue in how buffer size calculations are performed throughout the GStreamer codebase, rather than isolated mistakes in individual components. The volume and pattern suggest that the codebase would benefit from a systematic audit of all buffer size calculations using safe integer arithmetic, not just 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