Comparing changes

Bigint.from_msgpack_ext rebuilt the integer by shifting and adding one 32-bit chunk at a time. Each step copies the whole growing bignum, so decoding was quadratic in the payload length (a 1 MiB ext payload took over 20 seconds). Convert the chunks to a hex string and parse it in a single String#to_i(16), which runs in linear time. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

A container header carries an element count that the unpacker used to pre-allocate the Array or Hash. The count is capped at SHRT_MAX per container, but nested containers each pre-allocate up to that cap, so a small crafted message of deeply nested headers could still force a large allocation, and a streaming Unpacker holds it until the connection ends. An element needs at least one byte, so a container cannot hold more elements than there are bytes left to read. Cap the initial size by the buffered size as well; the container still grows as more data arrives. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix excessive memory allocation from crafted container headers

Speed up decoding of oversized integers

msgpack_buffer_append_string read the string's raw pointer up front and then grew the buffer. Growing it runs io.write (arbitrary Ruby) and can trigger GC, either of which may free or shrink the string's backing memory, so the later memcpy could read freed memory and copy heap contents into the output. Reserve the space first and read the pointer only afterwards, clamping and zero-filling if the string shrank in the meantime so the copy stays within the current buffer. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix use-after-free when packing a string into an IO

Navigation Menu

Repository navigation

Comparing changes

Open a pull request

Commits on Oct 11, 2026

This comparison is taking too long to generate.

Uh oh!