Callers of these APIs (especially on Wayland) currently uses different
strategies to scale the returned cursor to the size set by the user,
resulting in inconsistent cursor sizes and looks across different apps
and toolkits. Having the cursor scaled in libXcursor will skip app's
own scaling algorithm and guarantee a consistent look.
`*LoadAllImages()` are not changed. They still only return the sizes present
in the theme.
This change needs to be synchronized to libraries (libxcb-cursor, wayland),
toolkits (GTK), window managers / Wayland compositors (i3, wlroots) who have
a (modified) copy of libXcursor source code, in order to have a fully consistent
cursor size across all apps.
Signed-off-by: Jin Liu <m.liu.jin@gmail.com>
If a cursor file contains a header offset which is too small, ignore
the file instead of jumping to an incorrect offset.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
config.h is correctly included behind a HAVE_CONFIG_H guard earlier in
the file, so this isn't needed.
Signed-off-by: Robin Linden <dev@robinlinden.eu>
Found by gcc analyzer:
file.c: In function ‘XcursorXcFileLoad’:
file.c:782:8: warning: leak of ‘fileHeader’ [CWE-401] [-Wanalyzer-malloc-leak]
782 | if (!images)
| ^
Fixes: 3b84b14 ("Initial revision")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
_XcursorThemeInherits, XcursorWhite, & XcursorSep are copied in
libxcb-cursor/cursor/load_cursor.c and should be kept in sync
with changes to the libXcursor originals of those.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Handle themes with multiple inherit entries. Although the previous
commit keeped track of inherited themes, it only handled multiple theme
entries on the highest level.
This fix unconditionally checks if the next upper level contains a line.
If it does, it processes contained themes (i.e. the current theme had an
inherited entry in its index file).
If the upper level has no more themes, it goes down a level and
processes the next theme there. If no next theme exists, it moves down
another level and so on until it reaches level 0, i.e. the initially
supplied theme.
The lowest level (d = 0) is treated specially because we must not modify
the supplied theme, which could happen when calling _XcursorNextPath.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
This is a follow up for commit f64a8cc1a6
resulting from https://bugs.freedesktop.org/show_bug.cgi?id=3603
The current loop detection only works for direct self references but not
for transitive ones. Limiting the inheritance depth fixes this issue as
suggested by Keith Packard.
I avoided the introduction of a recursion function. Instead I modified
XcursorScanTheme to work iterative.
The current recursion code adds the "Inherits=..." line to heap and has
an iteration variable to go through all themes listed in that line per
recursion. This is covered with the newly introduced XcursorInherit
struct with its fields "line" and "theme". Since "theme" points into
"line", only "line" has to be freed eventually.
If a fixed inheritage limit of 32 is reached, the code stops processing
and returns NULL. It also returns NULL if it detects the initial theme
in one of the inheritages to break the loop early on.
Last but not least I removed the printf statement. The only situation in
which libXcursor writes to stdout is when it is explicitly requested.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
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.
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>
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>
Error: Memory leak (CWE 401)
Memory leak of pointer 'comments' allocated with XcursorCommentsCreate(0)
at line 982 of src/file.c in function 'XcursorFileSaveImages'.
'comments' allocated at line 978 with XcursorCommentsCreate(0).
comments leaks when comments != 0 at line 981.
[ 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>
