compress zstd: Panic on two-block frames
What fixes it
No source in this snapshot names a fixed version. The vendor advisories under References are the place to check.
Reports 1
1 outlet mention it. Reports are not confirmation; each links to its source.
Description
compress provides various compression algorithms. Prior to 1.20.2, the zstd DecodeAll and streaming decoder paths can panic when a crafted two-block frame reaches huff0.ReadTable with an FSE normalized count of 32768 that readNCount stores in int16 as -32768. The wrapped count allows buildDtable to retain stale fse.Scratch decode-table state from the prior block, and nextFast then derives an out-of-range state and indexes beyond the table instead of returning a decode error. Both blocks are required to preserve and then reuse the stale state, allowing untrusted zstd input to crash an application. This issue is fixed in version 1.20.2.
Text from CVE List
Affected versions 1
- compressaffected: < 1.20.2CVE List