Description

msgpack_unpacker_expand_buffer in src/unpack.c, reached through the public msgpack_unpacker_reserve_buffer API, computes its new buffer size using an unchecked size_t 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 SIZE_MAX 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/lib_buffer_unpack.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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-20T19:17:01.040Z",
  "pubdate": "2026-08-20T19:17:01.040Z",
  "executiveSummary": "The vulnerability is an unchecked integer addition leading to a heap buffer overflow in msgpack-c. Specifically, the flaw resides in the msgpack_unpacker_expand_buffer function located in src/unpack.c, accessible via the public msgpack_unpacker_reserve_buffer API. This vulnerability allows an attacker capable of supplying an attacker-influenced length to an integration using the reservation API—such as a length-prefixed streaming transport—to cause memory corruption.\nThe root cause is an unguarded size_t addition combining the requested size and the amount already used, which wraps around near SIZE_MAX. Due to this arithmetic overflow, the allocation function provisions a much smaller buffer than requested while falsely reporting success to the caller. Subsequent write operations based on the requested length result in a heap-based buffer overflow.\nThe impact of this vulnerability includes potential remote code execution, denial of service, or memory corruption within applications integrating msgpack-c insecurely. Exploitation requires an integration that passes untrusted, attacker-influenced lengths directly into the reservation API. Standard msgpack-c decode entry points do not inherently trigger this path unless exposed through custom streaming transports or parsing logic.\nRisk implications are severe for applications utilizing the reserve-then-write pattern, especially when reliance is placed on defensive assertions like those in example/lib_buffer_unpack.c that are compiled out in production builds under NDEBUG.",
  "technicalDetails": "The vulnerability occurs within the msgpack_unpacker_expand_buffer function in the src/unpack.c source file, which is reached directly through the public msgpack_unpacker_reserve_buffer API interface of the msgpack-c library.\nThe root cause of the vulnerability stems from insecure integer arithmetic during buffer size calculation. The function computes its new buffer size using a size_t addition that sums the requested size and the amount of buffer space already in use. While the internal doubling loop guards its multiplication operations against overflow, the initial addition within the loop condition lacks proper bounds checking and overflow validation.\nWhen an attacker supplies a crafted input near SIZE_MAX, the size_t addition wraps around. As a result of this integer wrap-around, the loop condition evaluates as already satisfied. The allocation routine bypasses necessary expansion steps and performs a memory allocation based on the small, pre-wrap size, yet the function ultimately returns true to the calling code.\nThe calling application is erroneously informed that the full requested capacity has been successfully reserved. Because the reserved buffer is significantly smaller than expected, a subsequent write operation of the full requested length triggers a severe heap buffer overflow.\nExploitation requires an application integration that derives the reservation size from untrusted input, such as a length-prefixed streaming transport protocol. The library's own example/lib_buffer_unpack.c illustrates the vulnerable reserve-then-write pattern, relying on defensive assert statements to compare capacity against requests—assertions that are stripped out in production environments compiled with NDEBUG.\nAuthentication and privilege requirements depend entirely on the surrounding application integrating the vulnerable msgpack-c library and exposing the streaming transport or parsing interface to the network or local users. Payload behavior involves supplying maliciously sized length headers to trigger the wrap-around, followed by data payloads that overflow the heap allocation, potentially leading to arbitrary code execution or application crashes."
}