I think similar code change as in https://github.com/ImageMagick/ImageMagick/commit/e6e874875e48dd9838acca3bd22c14a4d2f1b3ca commit could be applied to GraphicsMagick codebase. In other uses of ImageToBlob() the return value is checked (bmp.c,logo.c,xtrn.c,pict.c).
The JNG writer code does look pretty bad. It seems to be a prototype.
I did a search and see that CVE-2026-28690 is about a MNG encoder stack buffer overflow rather than a use of a null pointer in the JNG encoder. The ImageMagick project may have made other fixes while claiming to address CVE-2026-28690. It would be useful to know the details about where this stack buffer overflow happens. Are you able to determine this?
I do recall solving several MNG stack overflow issues in the past.
Eh yes, the main part of the patch seems to be in MNG code, or at least this CVE probably refers just to the last hunk, indeed. I was misled by the first two hunks, sorry for that.
I currently do not have any testcase, so this is just theoretical. Could it be that code may run out of space in chunk[] around
Write MNG PLTE chunk?There's very little information around these CVEs, unfortunately, but I can try to get more, if needed.
If CVEs provided adequate and complete descriptions of an issue, then the information could be used to immediately attack existing code. So they use vague obtuse descriptions which mean almost nothing.
Based on the last part of the ImageMagick edits, there may have been an overflow of the image colormap.
Change set 18010:967c71e2b740 provides necessary error handling for ImageToBlob(), as well as to assure that no more than 256 colors will be supplied to the MNG PLTE chunk.
Thanks!