newer groff (making select/paste useless), but is not necessary with
groff, mandoc or Solaris 10 nroff.
Signed-off-by: Thomas E. Dickey <dickey@invisible-island.net>
Without the casts the bytes accesses get converted to int. but int is
not guaranteed to be 4 bytes large. Even when it is 4 bytes large
`bytes[3] << 24` does not fit because int is signed.
This type is meant to be 4 bytes large as seen in _XcursorReadUInt which
always reads 4 bytes. An unsigned int is often 4 bytes large but this
isnt' guaranteed so it is cleaner to use the exact type we want.
Nowadays ~/.icons is not used anymore as the preferred location for
custom user icon themes; XDG_DATA_HOME/icons (aka ~/.local/share/icons)
is what toolkits like GTK prefer.
Prepend that location to the default xcursor path, so that cursor
themes installed there can be used by apps and toolkits that use
libXcursor.
It is possible to trigger heap overflows due to an integer overflow
while parsing images and a signedness issue while parsing comments.
The integer overflow occurs because the chosen limit 0x10000 for
dimensions is too large for 32 bit systems, because each pixel takes
4 bytes. Properly chosen values allow an overflow which in turn will
lead to less allocated memory than needed for subsequent reads.
The signedness bug is triggered by reading the length of a comment
as unsigned int, but casting it to int when calling the function
XcursorCommentCreate. Turning length into a negative value allows the
check against XCURSOR_COMMENT_MAX_LEN to pass, and the following
addition of sizeof (XcursorComment) + 1 makes it possible to allocate
less memory than needed for subsequent reads.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Reviewed-by: Matthieu Herrb <matthieu@herrb.eu>
Place quotes around the $srcdir, $ORIGDIR and $0 variables to prevent
fall-outs, when they contain space.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Syncs the invocation of configure with the one from the server.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Fix does one byte of memory allocation for null termination of string.
https://bugs.freedesktop.org/show_bug.cgi?id=90857
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
When parsing cursor files, a user defined (e.g. through environment
variables) cursor file is opened and parsed.
The header is read in _XcursorReadFileHeader(), which reads an unsigned
int for the number of toc structures in the header, but it was being
passed to _XcursorFileHeaderCreate() as a signed int to allocate those
structures. If the number was negative, it would pass the bounds check
and could overflow the calculation for how much memory to allocate to
store the data being read, leading to overflowing the buffer with the
data read from the user controlled file.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Excerpt https://lists.gnu.org/archive/html/automake/2012-12/msg00038.html
- Support for the long-deprecated INCLUDES variable will be removed
altogether in Automake 1.14. The AM_CPPFLAGS variable should be
used instead.
This variable was deprecated in Automake releases prior to 1.10, which is
the current minimum level required to build X.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Error: Null pointer dereference (CWE 476)
Read from null pointer 'info'
at line 615 of src/cursor.c in function 'XcursorImageLoadCursor'.
Function '_XcursorGetDisplayInfo' may return constant 'NULL' at line 134, called at line 597.
Null pointer introduced at line 134 of src/display.c in function '_XcursorGetDisplayInfo'.
[ This bug was found by the Parfait 0.3.7 bug checking tool.
For more information see http://labs.oracle.com/projects/parfait/ ]
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
