fix(zstd): return decode error instead of panicking on corrupt view lengths

[mvanhorn]

Summary

reconstruct_views decodes a [u32-LE length][value bytes] stream from ZSTD-decompressed (untrusted) data and used the length prefix as a slice bound without validation, so a corrupt or fuzzed length triggered an out-of-bounds slice panic (range end index ... out of range for slice of length ...). This makes reconstruct_views return VortexResult and bounds-checks the untrusted reads, returning a decode error instead of panicking.

Rationale for this change

This is a fuzzer-reported crash (#8822): decoding attacker-controllable ZSTD array data could panic a worker thread instead of surfacing a recoverable decode error. Decoding untrusted input should never panic; it should return an error the caller can handle. The panic reproduces on develop with a length prefix that exceeds the remaining buffer.

• Closes ZSTD decode OOB slice panic #8822

What changes are included in this PR?

• encodings/zstd/src/array.rs: reconstruct_views now returns VortexResult<(Vec<ByteBuffer>, Buffer<BinaryView>)>. Both untrusted reads (the view-length prefix and the value slice) are bounds-checked (with checked_add to avoid usize overflow) and return a decode error instead of panicking. The two in-crate callers propagate the error with ?.
• vortex-cuda/src/kernel/encodings/zstd.rs: the CUDA decode caller propagates the new error with ?.
• Added regression tests covering an oversized length prefix and a truncated length prefix; both now return Err rather than panicking. The existing reconstruct_views tests are unchanged in behavior.

What APIs are changed? Are there any user-facing changes?

The pub fn reconstruct_views in vortex-zstd changes its return type from (Vec<ByteBuffer>, Buffer<BinaryView>) to VortexResult<(Vec<ByteBuffer>, Buffer<BinaryView>)>. Decoding a corrupt ZSTD array now yields a VortexError instead of panicking. There is no behavior change for well-formed input.

AI was used for assistance.

[codspeed-hq]

Merging this PR will improve performance by 11.17%

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚡ 1 improved benchmark
✅ 1712 untouched benchmarks
⏩ 10 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	Simulation	true_count_vortex_buffer[128]	580.6 ns	522.2 ns	+11.17%

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing mvanhorn:fix/zstd-decode-oob-panic (eb172f4) with develop (c5e075a)}

Footnotes

1. 10 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[robert3005]

I think we are going to hold on making changes here until we have a complete solution for all invalid data paths since similar error to this was reported in #8821

[mvanhorn]

Makes sense, happy to hold until the invalid-data paths have a complete solution. Point me at the direction that comes out of #8821 and I'll adapt this or close it. DCO is fixed in the meantime.