Skip to content

Fix decompression bomb vulnerability in DecodeStream#1779

Closed
eddieran wants to merge 1 commit intoHopding:masterfrom
eddieran:fix/decode-stream-buffer-limit
Closed

Fix decompression bomb vulnerability in DecodeStream#1779
eddieran wants to merge 1 commit intoHopding:masterfrom
eddieran:fix/decode-stream-buffer-limit

Conversation

@eddieran
Copy link
Copy Markdown

Summary

Adds a maximum buffer size limit to DecodeStream.ensureBuffer() to prevent decompression bomb attacks.

  • ensureBuffer() previously doubled its buffer without any upper bound, allowing a crafted Flate/LZW stream to allocate gigabytes of memory and crash the process during PDFDocument.load()
  • Adds a configurable static maxBufferSize property (default 256 MB) that throws a descriptive error when exceeded
  • Users can adjust the limit via DecodeStream.maxBufferSize for legitimate large documents

Fixes #1777

Changes

src/core/streams/DecodeStream.ts:

  • Added DEFAULT_MAX_BUFFER_SIZE constant (256 MB)
  • Added static maxBufferSize property to DecodeStream class
  • Added bounds check in ensureBuffer() before buffer allocation

Test plan

  • Verify normal PDF loading still works (buffer stays well under 256 MB for typical documents)
  • Verify that a crafted PDF with a high-ratio compressed stream throws an error instead of consuming all memory
  • Verify DecodeStream.maxBufferSize can be increased for legitimate large documents

DecodeStream.ensureBuffer() doubles its buffer without any upper bound,
allowing crafted compressed streams to allocate gigabytes of memory and
crash the process. Add a configurable maximum buffer size (default 256 MB)
that throws a clear error when exceeded.

Fixes #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