CVE-2026-72854

ŚrednieCVSS 5.3

Opublikowano: 20/08/2026(UTC)Przetłumaczono: 21/08/2026(UTC)NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko

0.11%

Percentyl 2 - wyżej niż 2% wszystkich znanych CVE

Streszczenie

msgpack_unpacker_expand_buffer w src/unpack.c, osiągany przez publiczne API msgpack_unpacker_reserve_buffer, oblicza nowy rozmiar bufora używając niesprawdzonego dodawania size_t żądanego rozmiaru i już użytej ilości. Pętla podwajania chroni swoje mnożenie przed przepełnieniem, ale dodawanie w warunku pętli jest niechronione, więc żądanie bliskie SIZE_MAX zawija się: warunek pętli jest już spełniony, alokacja jest wykonywana przy małym rozmiarze przed zawinięciem, a funkcja zwraca true. Wywołujący jest informowany, że żądana pojemność została zarezerwowana, gdy nie została, więc późniejszy zapis żądanej długości przepełnia bufor sterty.

Ocena ryzyka

Może to prowadzić do przepełnienia bufora sterty, co może umożliwić zdalne wykonanie kodu lub awarię aplikacji, jeśli integracja przekazuje długość kontrolowaną przez atakującego do API rezerwacji.

Rekomendacja

Zaktualizuj msgpack-c do wersji zawierającej poprawkę. Upewnij się, że integracje nie przekazują długości kontrolowanych przez atakującego do API rezerwacji bez walidacji.

Powiązane podatności

Oryginalny opis (angielski, źródło NVD)

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.