ZstdDecompressor.decompress: excessive allocation (crash) on 13-byte malformed frame (decompressor.c:335); should raise ZstdError
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 72/100
Research direction
Start at c-ext/decompressor.c:335 and reproduce the issue with the supplied 13-byte malformed frame. Trace how the frame content size reaches allocation and how decompression errors become ZstdError; done means malformed input is rejected without an oversized allocation and regression coverage verifies the failure.
Written by the indexing model from the issue text.
Description
Repo
Summary
ZstdDecompressor().decompress() pre-allocates the full Frame_Content_Size (FCS) from the frame header WITHOUT capping; a 13-byte malformed frame declaring a corrupt FCS makes it call PyBytes_FromStringAndSize for a ~1.1 TB buffer at c-ext/decompressor.c:335, causing an ASan allocation-size-too-big ABORT (in production: a huge MemoryError) — i.e. a crash/DoS on a tiny untrusted decompression input, rather than the documented ZstdError.
Trigger (13 bytes)
hex: 28b52ffde06c06060663636363
Evidence
ASan (binding C-ext built with -fsanitize=address):
ERROR: AddressSanitizer: requested allocation size 0x66c6c6c00000121 exceeds maximum supported size
#3 PyBytes_FromStringAndSize
#4 Decompressor_decompress c-ext/decompressor.c:335
SUMMARY: AddressSanitizer: allocation-size-too-big
ABORTING
Expected
The Frame_Content_Size field of a malformed/short frame must not cause an over-allocation; the decompressor should reject such input (raise ZstdError / cap the buffer & grow dynamically), as single-shot malloc of an attacker-controlled FCS is unsafe (CWE-789).
Note
This binding C-ext path is NOT covered by OSS-Fuzz (only upstream zstd core is) and has no advisory.
- Dominant language
- C
- Stars
- 642
- Forks
- 116
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 5
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from indygreg/python-zstandard
-
`multi_decompress_to_buffer([])` terminates the process with SIGFPEPossibly taken @mikamikasuki claimed this 3 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
indygreg/python-zstandard#335 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
indygreg/python-zstandard#295 ·
Maintainers usually reply within 2 days
-
Difficulty 3/5 1-2 days Newbie friendliness 64/100
indygreg/python-zstandard#345 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
indygreg/python-zstandard#334 ·
Maintainers usually reply within 2 days
-
Difficulty 3/5 1-2 days Newbie friendliness 54/100
indygreg/python-zstandard#333 ·
Maintainers usually reply within 2 days
All issues in indygreg/python-zstandard
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
libsdl-org/SDL#16444 ·
Maintainers usually reply within 1 day
-
bug Component component: net
Difficulty 1/5 Under an hour Newbie friendliness 90/100
RT-Thread/rt-thread#11852 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
MiSTer-devel/ao486_MiSTer#243 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
siderolabs/pkgs#1710 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day