When reading XPM images from a file with libXpm 3.5.14 or older, if a
comment in the file is not closed (i.e. a C-style comment starts with
"/*" and is missing the closing "*/"), the ParseComment() function will
loop forever calling getc() to try to read the rest of the comment,
failing to notice that it has returned EOF, which may cause a denial of
service to the calling program.

Reported-by: Marco Ivaldi <[email protected]>
Signed-off-by: Alan Coopersmith <[email protected]>

When reading XPM images from a file with libXpm 3.5.14 or older, if a
image has a width of 0 and a very large height, the ParsePixels() function
will loop over the entire height calling getc() and ungetc() repeatedly,
or in some circumstances, may loop seemingly forever, which may cause a
denial of service to the calling program when given a small crafted XPM
file to parse.

Closes: winlibs#2

Reported-by: Martin Ettl <[email protected]>
Signed-off-by: Alan Coopersmith <[email protected]>

xpmParseDataAndCreate() calls XDestroyImage() in the error path.
Reproducible with sxpm "zero-width.xpm", that file is in the test/
directory.

The same approach is needed in the bytes_per_line == 0 condition though
here it just plugs a memory leak.

Signed-off-by: Alan Coopersmith <[email protected]>

When the test case for CVE-2022-46285 was run with the Address Sanitizer
enabled, it found an out-of-bounds read in ParseComment() when reading
from a memory buffer instead of a file, as it continued to look for the
closing comment marker past the end of the buffer.

Signed-off-by: Alan Coopersmith <[email protected]>

Found with clang's libfuzzer

Signed-off-by: Alan Coopersmith <[email protected]>