[ilyas-mallah]

What and why

ZSTD_decompressBound() is documented as an upper bound on the decompressed size, but two kinds of input make it return less than ZSTD_decompress() produces. The decoder still honors dstCapacity, so a caller that allocates the bound gets dstSize_tooSmall on input that otherwise decodes.

1. Overflow. Frame content sizes are summed without an overflow check, so two frames that each declare 2^63 bytes give a bound of 0. ZSTD_findDecompressedSize() already guards the same sum, and ZSTD_decompressBound() now does too.
2. Oversized Raw and RLE blocks. Single-pass decoding accepts Raw and RLE blocks larger than blockSizeMax (spec: 0-sized compressed blocks in frames with window_size = 0 #3482), but the bound counts every block as blockSizeMax. A 10-byte frame with one RLE block decodes to 17,597 bytes against a bound of 6,144. Such blocks now count at their declared size, and valid frames keep the same bound.

The other way to fix the second case is to reject these blocks in ZSTD_decompressFrame(), as streaming does and as the spec says (#4669). That changes which inputs decode, so this PR keeps them decodable and only fixes the bound. I can switch to rejecting them if that's preferred.

A new unit test fails on dev, and two fuzz targets now check the bound, skipping legacy frames since the frozen legacy decoders don't keep it. tests/fuzzer (64-bit and 32-bit), test-fuzzer and test-legacy pass, and 300 s per fuzz target with ASan and UBSan found nothing.

Checklist

• I searched open pull requests and issues: this problem is not already being addressed.
• Bug fix: it comes with a reproducer or a test that fails without the fix.
• Performance change: numbers from repeated runs are included, with CPU, compiler, flags and data.
• I stated below whether AI or other automated tools were used.

Tools used

AI usage: Claude Code helped with the fuzzing runs and test builds. I traced both cases, made the fix, and validated every change.

[meta-cla]

Hi @ilyas-mallah!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[ilyas-mallah]

@terrelln @Cyan4973 The open question in the description: should single-pass decoding reject Raw and RLE blocks above Block_Maximum_Size (#4669), instead of the bound counting them? I kept them decodable because rejecting changes which inputs decode. I can rework it to reject if you'd rather. Could one of you also approve the workflow run? No CI has run here or on #4833 and #4834, two small separate fixes (zstd -l and ZSTD_frameHeaderSize()). dev hasn't moved since I opened them, so nothing needs a rebase.

[ilyas-mallah]

@Cyan4973 @terrelln Two small separate fixes wait only on the first workflow approval: #4833 (zstd -l hang on a large skippable frame) and #4834 (ZSTD_frameHeaderSize for skippable frames). Neither depends on #4832 or the other. Could one of you approve the run and say if either needs a change?