CVE-2026-72854: msgpack-c Integer Overflow in msgpack_unpacker_expand_buffer Causes a False-Success Undersized Reservation
msgpackunpackerexpandbuffer in src/unpack.c, reached through the public msgpackunpackerreservebuffer API, computes its new buffer size using an unchecked sizet addition of the requested size and the amount already used. The doubling loop guards its own multiplication against overflow, but the addition in the loop condition is unguarded, so a request near SIZEMAX wraps: the loop condition is already satisfied, the allocation is performed at the small pre-wrap size, and the function returns true. The caller is told the requested capacity was reserved when it was not, so a subsequent write of the requested length overflows the heap buffer. The library's own example/libbufferunpack.c demonstrates the reserve-then-write pattern, and its defensive assert comparing capacity against the request is compiled out under NDEBUG. msgpack-c's own decode entry points do not derive the reservation size from untrusted input, so reaching this requires an integration that passes an attacker-influenced length to the reservation API, such as a length-prefixed streaming transport.
Affected Software
Event History
Frequently Asked Questions
Which integrations are realistically exposed to this issue?
Exposure requires an application to call the public msgpack_unpacker_reserve_buffer API with an attacker-influenced requested length. A length-prefixed streaming transport is an example; msgpack-c's own decode entry points do not derive the reservation size from untrusted input.
What must happen for exploitation to lead to a heap overflow?
The requested reservation size must be near SIZE_MAX so that adding it to the currently used buffer size wraps. The API then reports success after allocating only the small pre-wrap size, and the caller must subsequently write the originally requested length into that undersized buffer.
Does a successful reservation call guarantee that the requested capacity is available?
No. Under the overflow condition, msgpack_unpacker_reserve_buffer can return true even though it did not reserve the requested capacity. The example's capacity-versus-request assert would detect this condition, but it is compiled out when NDEBUG is defined.