Skip to content

fix: add decompression size limit to prevent decompression bomb DoS#1780

Open
eddieran wants to merge 1 commit intoHopding:masterfrom
eddieran:fix/decompression-bomb
Open

fix: add decompression size limit to prevent decompression bomb DoS#1780
eddieran wants to merge 1 commit intoHopding:masterfrom
eddieran:fix/decompression-bomb

Conversation

@eddieran
Copy link
Copy Markdown

Summary

Adds a configurable maximum decompressed size limit to DecodeStream to prevent decompression bomb denial-of-service attacks.

Problem: A crafted PDF can contain a small compressed stream that expands into gigabytes of data when decompressed, exhausting the host's available memory (decompression bomb / zip bomb). The DecodeStream base class had no upper bound on buffer growth — ensureBuffer() would keep doubling the internal buffer indefinitely.

Fix: Enforce a maximum decompressed size (default 100 MB) in ensureBuffer(). When the accumulated output exceeds this threshold, an error is thrown instead of continuing to allocate memory. The limit is configurable via the maxDecompressedSize constructor parameter for users who need to process legitimately large streams.

Changes

  • Added DEFAULT_MAX_DECOMPRESSED_SIZE constant (100 MB)
  • Added maxDecompressedSize parameter to DecodeStream constructor (with default)
  • Added size check in ensureBuffer() that throws before allocating beyond the limit

Backward Compatibility

The new parameter has a default value, so all existing subclasses (FlateStream, LZWStream, AsciiHexStream, Ascii85Stream, RunLengthStream) work without modification. The 100 MB default is large enough for any legitimate PDF content.

Fixes #1777. Replaces #1779 (which was auto-closed when the source fork was deleted).

Add a configurable maximum decompressed size limit (default 100 MB) to
DecodeStream. When the accumulated decompressed output exceeds this
threshold, an error is thrown instead of continuing to allocate memory.

This prevents denial-of-service attacks where a small, crafted
compressed PDF stream expands into gigabytes of data, exhausting the
host's available memory.

The limit is enforced in ensureBuffer() and defaults to 100 MB, which
is sufficient for legitimate PDF content while blocking pathological
expansion ratios.

Fixes Hopding#1777
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unbounded buffer growth in DecodeStream enables decompression bomb DoS

1 participant