WASM/PE: cap embedded Portable PDB decompression size (zip-bomb hardening)

[BYK]

Follow-up from @Dav1dde's review comment on #1004: #1004 (comment)

Problem

PeEmbeddedPortablePDB::decompress_to (symbolic-debuginfo/src/pe.rs) inflates the entire deflate stream into the output writer with no size cap. #1004 removed the speculative Vec::with_capacity(get_size()) pre-allocation (the uncompressed_size field is an attacker-controlled u32 PE header value), so we no longer over-allocate from an untrusted size — but a crafted PE can still expand a small compressed blob into a very large output (a classic decompression bomb).

Notably, ParseObjectOptions::max_decompressed_embedded_source_size already exists and is honored for source bundles / PPDB source files, but it is not wired into the embedded-PPDB extraction path.

Proposed fix

Thread a decompression limit into the embedded-PPDB path:

• Store the relevant limit on PeObject during parse_with_opts (currently _opts is ignored at pe.rs:400) and pass it down to PeEmbeddedPortablePDB.
• Enforce the cap in decompress_to (e.g. wrap the writer in a byte-counting/limited writer and error out once the limit is exceeded), rather than trusting the header size.
• Reuse max_decompressed_embedded_source_size if its semantics fit ("compressed data embedded in an object"), or add a dedicated ParseObjectOptions field.

This is a symbolic-debuginfo core change (affects native + all consumers), which is why it's split out rather than bolted onto the WASM PR.

Notes / non-urgency

• Per @Dav1dde, this is not an issue for the sentry-cli use case (it reads local debug files the developer owns, not untrusted input).
• The fix is non-breaking for the WASM bindings: the limit is plumbed via parse options (optional/defaulted), so the public ObjectFile.asPe() / PeFile.embeddedPpdb() API added in feat(wasm): expose ObjectFile.embeddedPpdb() for embedded Portable PDB extraction #1004 does not change.

[linear-code]

SYMBOL-27

[Whatsonyourmind]

Had a look at pe.rs — since #1004 already dropped the Vec::with_capacity(get_size()), the only remaining exposure is exactly the streaming inflate in decompress_to, and the write-side decoder makes the cap clean to add. Two thoughts, one on your open question:

Reuse vs. a dedicated field — I'd add a dedicated one. max_decompressed_embedded_source_size is used in ppdb.rs / sourcebundle for individual embedded source files — the decompressed size of one source document. The embedded PPDB here is the whole PPDB stream (metadata + many source files), so it's legitimately an order of magnitude larger. Reuse forces a bad choice: set the limit high enough for a whole PPDB (weakening the per-source-file protection everywhere else) or leave it where it is (false-tripping legitimately large PPDBs). A separate max_decompressed_ppdb_size keeps the two independent — a per-item cap and a whole-container cap are genuinely different controls.

The cap belongs on the output writer, ~15 lines. Because decompress_to uses flate2::write::DeflateDecoder::new(output), the inflated bytes land in output incrementally as write_all(compressed_data) runs — so wrapping output in a byte-counting writer trips mid-inflation, keeping peak memory bounded by the cap rather than by the (attacker-declared) full size:

struct LimitedWriter<W> { inner: W, remaining: u64 }

impl<W: Write> Write for LimitedWriter<W> {
    fn write(&mut self, buf: &[u8]) -> io::Result<usize> {
        if buf.len() as u64 > self.remaining {
            return Err(io::Error::new(
                io::ErrorKind::InvalidData,
                "embedded Portable PDB exceeds decompression limit",
            ));
        }
        let n = self.inner.write(buf)?;
        self.remaining -= n as u64;
        Ok(n)
    }
    fn flush(&mut self) -> io::Result<()> { self.inner.flush() }
}

decompress_to(output, limit) then wraps output as LimitedWriter { inner: output, remaining: limit.unwrap_or(u64::MAX) } before handing it to the decoder; decoder.finish() surfaces the error. The limit is the thing you plumb from PeObject (the _opts currently dropped at pe.rs:400). Note it never reads self.uncompressed_size — which is the point: the header value stays untrusted.

Happy to put this up as a PR against symbolic-debuginfo (LimitedWriter + the _opts threading + a dedicated option field + a crafted-blob test). One honest caveat: I don't have a local Rust toolchain to run cargo test --workspace, so I'd lean on your CI to gate it — or if you'd rather keep the option plumbing in-house, I'm glad to just hand over the writer + a regression test. Either way it's small and self-contained.