Тогда откуда эта новость? Либо кто то выдумал эти ошибки в надежде что люди не проверят. Либо любители раста подкинули кривой код.

И как обычно все четыре из четырех уязвимостей из-за того, что dыpяшeчники не могут в память.
Никогда такого не было и и вот опять)

С одной стороны ничего нового, типиkaл си код.

Но один пикантный момент в новости упустили - этой dыpeни уже почти десять лет :)

Была добавлена в январе 2016 в коммите Simplified API: write-to-memory, overflow handling [1], в котором исправляли ДРУГИЕ проблемы с переполнениями при обработке изображений.

/* Now check for overflow of the image buffer calculation; this
* limits the whole image size to 32 bits for API compatibility with
* the current, 32-bit, PNG_IMAGE_BUFFER_SIZE macro.
*/
Pathetic))

И почти десять лет выполнения стороннего кода при обработке специально оформленных файлов в огромном количестве пакетов! Все это время проблема оставалась незамеченной. Тыщща глаз смотрела куда-то не туда.

Добавил это в уточнение в новость, но не уверен что пропустят.
Поэтому продублирую тут чтобы порадовать всех))

[1] github.com/pnggroup/libpng/commit/175a126a1a9ecb8ffb26882f5fc0b509fecc656a

2015-11-15 libpng buffer overflow in png_set_PLTE
2015-01-05 png -- heap overflow for 32-bit builds
2012-04-08 png -- memory corruption/possible remote code execution
2010-06-28 png -- libpng decompression buffer overflow
2010-04-20 png -- libpng decompression denial of service
2008-04-25 png -- unknown chunk processing uninitialized memory access
2007-10-11 png -- multiple vulnerabilities
2007-05-16 png -- DoS crash vulnerability
2004-08-04 libpng stack-based buffer overflow and other code concerns
2004-05-02 libpng denial-of-service

Что какбЭ в полной мере характеризует качество кода этой либы и йазычка, на которой она написана.