Hi @byroot, @frsyuki, @tagomoris,
I've submitted a pull request to integrate msgpack-ruby into Google OSS-Fuzz — Google's free continuous fuzzing infrastructure for open source projects.
OSS-Fuzz PR: google/oss-fuzz#15340
What this does
Once merged, Google's ClusterFuzz infrastructure will run two fuzz targets against msgpack-ruby 24/7:
fuzz_unpack — exercises MessagePack.unpack with option variants (symbolize_keys, freeze, allow_unknown_ext, key_cache)fuzz_unpack_stream — exercises the streaming Unpacker API (feed_each, feed+each, feed+loop{read})
Any memory safety bugs found (buffer overflows, use-after-free, etc.) are automatically reported to you privately, with a 90-day disclosure deadline.
Finding already discovered
The fuzzer immediately found a DoS condition:
ext/msgpack/unpacker.c:339 — rb_str_buf_new(length) is called with the length from the msgpack header (str32/bin32 can specify up to 4GB) before checking whether that much data is available in the buffer. A crafted 5-byte message can force a 4GB allocation attempt.
Suggested fix: Check msgpack_buffer_total_readable_size(UNPACKER_BUFFER_(uk)) against length before calling rb_str_buf_new(length) in read_raw_body_cont. If length > available_bytes, return PRIMITIVE_EOF (or a new PRIMITIVE_MALFORMED) instead of pre-allocating.
Benefits to the project
- Free — no cost to you
- Continuous — runs on Google's infrastructure indefinitely
- Automatic triage — crashes are deduplicated and reported with minimal input reproducer
- Any bugs found go to your private inbox before public disclosure
Request
Could you leave an LGTM comment on the OSS-Fuzz PR (google/oss-fuzz#15340)? The Google reviewers require acknowledgment from an upstream maintainer before merging.
Happy to answer any questions about what gets fuzzed or how the harnesses work.
Thank you!
Hi @byroot, @frsyuki, @tagomoris,
I've submitted a pull request to integrate msgpack-ruby into Google OSS-Fuzz — Google's free continuous fuzzing infrastructure for open source projects.
OSS-Fuzz PR: google/oss-fuzz#15340
What this does
Once merged, Google's ClusterFuzz infrastructure will run two fuzz targets against msgpack-ruby 24/7:
fuzz_unpack— exercisesMessagePack.unpackwith option variants (symbolize_keys,freeze,allow_unknown_ext,key_cache)fuzz_unpack_stream— exercises the streamingUnpackerAPI (feed_each,feed+each,feed+loop{read})Any memory safety bugs found (buffer overflows, use-after-free, etc.) are automatically reported to you privately, with a 90-day disclosure deadline.
Finding already discovered
The fuzzer immediately found a DoS condition:
ext/msgpack/unpacker.c:339—rb_str_buf_new(length)is called with the length from the msgpack header (str32/bin32 can specify up to 4GB) before checking whether that much data is available in the buffer. A crafted 5-byte message can force a 4GB allocation attempt.Suggested fix: Check
msgpack_buffer_total_readable_size(UNPACKER_BUFFER_(uk))againstlengthbefore callingrb_str_buf_new(length)inread_raw_body_cont. Iflength > available_bytes, returnPRIMITIVE_EOF(or a newPRIMITIVE_MALFORMED) instead of pre-allocating.Benefits to the project
Request
Could you leave an LGTM comment on the OSS-Fuzz PR (google/oss-fuzz#15340)? The Google reviewers require acknowledgment from an upstream maintainer before merging.
Happy to answer any questions about what gets fuzzed or how the harnesses work.
Thank you!