Currently, when the X server crashes or a client is disconnected with
XKillClient, you get a somewhat confusing error message from libX11
along the lines of:
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
after 98 requests (40 known processed) with 0 events remaining.
What's happening here is the previous recvmsg has thrown EAGAIN, since
the socket is non-blocking. In this case, check whether the socket has
any more data to read, and if not treat it like EPIPE.
Signed-off-by: Adam Jackson <ajax@redhat.com>
In-tree builds found reallocarray.h in $(top_builddir)/src but the
out-of-tree build didn't find it at all.
Reported-by: Emmanuele Bassi <ebassi@gmail.com> from GNOME continuous integration pipeline
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Makes resizing & clearing more consistent and gets rid of some weird
quirks like always subtracting 1 from the size passed to _XkbClearElems
so it could always add 1 to the size passed in.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Wrapper for realloc() that checks for overflow when multiplying
arguments together, so we don't have to add overflow checks to
every single call. For documentation on usage, see:
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/calloc.3
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
It avoids reading from the display connection again in cases where that
was already done.
Suggested-by: Uli Schlachter <psychon@znc.in>
Reviewed-by: Uli Schlachter <psychon@znc.in>
If xcb_poll_for_reply fails to find a reply, poll_for_response would
always return NULL. However, xcb_poll_for_reply may have read events
from the display connection while looking for a reply. In that case,
returning NULL from poll_for_response is wrong and can result in the
client hanging, e.g. because it returns to waiting for the display
connection file descriptor becoming readable after XPending incorrectly
returned 0 pending events.
The solution is to call poll_for_event again after xcb_poll_for_reply
returned 0. This will return the first of any events read by
xcb_poll_for_reply.
Fixes issue #79.
Reported-by: Yuxuan Shui <yshuiv7@gmail.com>
Bugzilla: https://bugs.freedesktop.org/108008
Bugzilla: https://bugs.freedesktop.org/107992
Reviewed-by: Adam Jackson <ajax@redhat.com>
If the server sends a reply in which even the first string would
overflow the transmitted bytes, list[0] (or flist[0]) will be set to
NULL and a count of 0 is returned.
If the resulting list is freed with XFreeExtensionList or
XFreeFontPath later on, the first Xfree call:
Xfree (list[0]-1)
turns into
Xfree (NULL-1)
which will most likely trigger a segmentation fault.
I have modified the code to return NULL if the first string would
overflow, thus protecting the freeing functions later on.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
The length value is interpreted as signed char on many systems
(depending on default signedness of char), which can lead to an out of
boundary write up to 128 bytes in front of the allocated storage, but
limited to NUL byte(s).
Casting the length value to unsigned char fixes the problem and allows
string values with up to 255 characters.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
The functions XGetFontPath, XListExtensions, and XListFonts are
vulnerable to an off-by-one override on malicious server responses.
The server replies consist of chunks consisting of a length byte
followed by actual string, which is not NUL-terminated.
While parsing the response, the length byte is overridden with '\0',
thus the memory area can be used as storage of C strings later on. To
be able to NUL-terminate the last string, the buffer is reserved with
an additional byte of space.
For a boundary check, the variable chend (end of ch) was introduced,
pointing at the end of the buffer which ch initially points to.
Unfortunately there is a difference in handling "the end of ch".
While chend points at the first byte that must not be written to,
the for-loop uses chend as the last byte that can be written to.
Therefore, an off-by-one can occur.
I have refactored the code so chend actually points to the last byte
that can be written to without an out of boundary access. As it is not
possible to achieve "ch + length < chend" and "ch + length + 1 > chend"
with the corrected chend meaning, I removed the inner if-check.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
If a server sends an incorrect length in its response, a client is prone
to perform an out of boundary read while processing the data.
The length field of xHostEntry is used to specify the amount of bytes
used to represent the address. It is 16 bit, which means that it is not
possible to perform an arbitrary memory access, but it might be enough
to read sensitive information, e.g. malloc-related pointers and offsets.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Reviewed-by: Matthieu Herrb <matthieu@herrb.eu>
ks_tables.h is always considered out of date due to the forced rebuild
of the makekeys util. This means the file is also rebuilt during 'make
install', which is usually performed as root, which can to lead
permission problems later on.
Signed-off-by: Martin Natano <natano@natano.net>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
These variables store values returned from strlen() as a size_t
and are passed to Xmalloc, which expects a size_t, so lets stop
converting back and forth to int along the way.
Reported by: Konstantin SKliarov
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Matthieu Herrb <matthieu@herrb.eu>
The _XimCacheStruct structure is followed in memory by two strings containing
fname and encoding. The memory was accessed using the last member of the
structure `char fname[1]`. That is a lie, prohibits us from using sizeof and
confuses checkers. Lets declare it properly as a flexible array, so compilers
don't complain about writing past that array. As bonus we can replace the
XOffsetOf with regular sizeof.
Fixes GCC8 error:
In function 'strcpy',
inlined from '_XimWriteCachedDefaultTree' at imLcIm.c:479:5,
inlined from '_XimCreateDefaultTree' at imLcIm.c:616:2,
inlined from '_XimLocalOpenIM' at imLcIm.c:700:5:
/usr/include/bits/string_fortified.h:90:10: error: '__builtin_strcpy'
forming offset 2 is out of the bounds [0, 1] [-Werror=array-bounds]
return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
Caused by this line seemingly writing past the fname[1] array:
imLcIm.c:479: strcpy (m->fname+strlen(name)+1, encoding);
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes: warning: variable 'req' set but not used [-Wunused-but-set-variable]
by marking req _X_UNUSED
Solution was discussed on xorg-devel ML
Peter Hutter, Alan Coopersmith
Re: [PATCH libX11 3/5] fix: warning: pointer targets in passing argument 2 of '_XSend' differ in signedness [-Wpointer-sign]
Signed-off-by: harms wharms@bfs.de
You can save a bit of code. The is no need to check XFree arguments bring free_fontdataOM in line with other free function and check for NULL arg
Signed-off-by: harms wharms@bfs.de
