- 19 Oct, 2016 6 commits
-
-
Pauli Nieminen authored
If we receive unsupported event closing connection triggers valgrind error. ==12017== Conditional jump or move depends on uninitialised value(s) ==12017== at 0x487D454: _XFreeDisplayStructure (OpenDis.c:607) ==12017== by 0x486857B: XCloseDisplay (ClDisplay.c:72) *snip* ==12017== Uninitialised value was created by a heap allocation ==12017== at 0x4834C48: malloc (vg_replace_malloc.c:236) ==12017== by 0x4894147: _XEnq (XlibInt.c:877) ==12017== by 0x4891BF3: handle_response (xcb_io.c:335) ==12017== by 0x4892263: _XReply (xcb_io.c:626) *snip* Problem is that XFreeDisplaySturture is checking for qelt->event.type == GenericEvent while _XUnknownWireEvent doesn't store the type. Reviewed-by:
Adam Jackson <ajax@redhat.com> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
Pauli Nieminen <ext-pauli.nieminen@nokia.com> Backported-to-NX-by:
Ulrich Sibiller <uli42@gmx.de>
-
Alan Coopersmith authored
One of the malloc failure checks had a goto to the wrong spot in the list of cleanup free() calls to unwind at the end, and was freeing bits that hadn't been initialized/allocated yet, since they would be stored in the struct that just failed to be allocated. Error: Null pointer dereference (CWE 476) Read from pointer that could be constant 'NULL' at line 805 of /export/alanc/X.Org/sx86/lib/libX11/nx-X11/lib/X11/LRGB.c in function 'LINEAR_RGB_InitSCCData'. Pointer checked against constant 'NULL' at line 754 but does not protect the dereference. [ This bug was found by the Parfait bug checking tool. For more information see http://research.sun.com/projects/parfait ] Signed-off-by:Alan Coopersmith <alan.coopersmith@oracle.com> Backported-to-NX-by:
-
Daniel Stone authored
If we get input in the style of 0xdeadbeef, just return that exact keysym. Introduces a dependency on strtoul, which I'm told is OK on all the systems we care about. Signed-off-by:
Daniel Stone <daniel@fooishbar.org> Backported-to-NX-by:
-
Daniel Stone authored
Signed-off-by:
Keith Packard <keithp@keithp.com> Backported-to-NX-by:
-
Daniel Stone authored
Since XStringToKeysym now supports all the vendor keysyms, just delete our XKeysymDB, which was incomplete at best, misleading at worst, and always an annoyance. Signed-off-by:
-
Daniel Stone authored
Some XFree86 keysyms were in XKeysymDB as XF86_foo, despite really being XF86foo. So, if we get to the bottom of XStringToKeysym and haven't found our XF86_foo, try it again as XF86foo. Signed-off-by:
-
- 14 Oct, 2016 2 commits
-
-
Mike Gabriel authored
debian/rules: Don't use -pie -fPIE at build time for 3.5.99.2 as it causes nxagent to segfault. Investigating the reasons behind it is in process...
-
Mihai Moldovan authored
The typo didn't cause immediate problems.
-
- 13 Oct, 2016 9 commits
-
-
Mike Gabriel authored
-
Mike Gabriel authored
-
Mike Gabriel authored
debian/rules: Don't modify/create post{inst,rm} scripts during dh_makeshlibs. This avoids adding ldconfig calls to such scripts. -
Mike Gabriel authored
-
Mike Gabriel authored
-
Mike Gabriel authored
-
Ulrich Sibiller authored
-
Ulrich Sibiller authored
-
Mike Gabriel authored
Attributes GH PR #215: https://github.com/ArcticaProject/nx-libs/pull/215
-
- 12 Oct, 2016 23 commits
-
-
Julien Cristau authored
Add a couple fixups for the security patches - off-by-one in xkb - memory leak in an error path Backport from debian to NX: Ulrich Sibiller <uli42@gmx.de> -
Matthieu Herrb authored
Freeing a pointer that wasn't returned by malloc() is undefined behavior and produces an error with OpenBSD's implementation. Signed-off-by:
Matthieu Herrb <matthieu.herrb@laas.fr> Reviewed-by:
Julien Cristau <jcristau@debian.org> Backported-to-NX-by:
-
Alan Coopersmith authored
Various other bounds checks in the code assume this is true, so enforce it when we first get the data from the X server. Signed-off-by:
-
Alan Coopersmith authored
Prevents trying to free uninitialized pointers if we have to bail out partway through setup, such as if we receive a corrupted or incomplete connection setup block from the server. Signed-off-by:
-
Alan Coopersmith authored
parseline() can call _XimParseStringFile() which can call parseline() which can call _XimParseStringFile() which can call parseline() .... eventually causing recursive stack overflow and crash. Limit is set to a include depth of 100 files, which should be enough for all known use cases, but could be adjusted later if necessary. Reported-by:
Ilja Van Sprundel <ivansprundel@ioactive.com> Signed-off-by:
-
Alan Coopersmith authored
GetIncludeFile() can call GetDatabase() which can call GetIncludeFile() which can call GetDatabase() which can call GetIncludeFile() .... eventually causing recursive stack overflow and crash. Easily reproduced with a resource file that #includes itself. Limit is set to a include depth of 100 files, which should be enough for all known use cases, but could be adjusted later if necessary. Reported-by:
-
Alan Coopersmith authored
Ensure that when breaking the returned list into individual strings, we don't walk past the end of allocated memory to write the '\0' bytes Signed-off-by:
-
Alan Coopersmith authored
Ensure that when breaking the returned list into individual strings, we don't walk past the end of allocated memory to write the '\0' bytes Signed-off-by:
-
Alan Coopersmith authored
Ensure that when breaking the returned list into individual strings, we don't walk past the end of allocated memory to write the '\0' bytes Signed-off-by:
-
Alan Coopersmith authored
Check the provided buffer size against the amount of data we're going to write into it, not against the reported length from the ClientMessage. Reported-by:
-
Alan Coopersmith authored
If the X server returns key name indexes outside the range of the number of keys it told us to allocate, out of bounds memory writes could occur. Reported-by:
-
Alan Coopersmith authored
If the X server returns modifier map indexes outside the range of the number of keys it told us to allocate, out of bounds memory writes could occur. Reported-by:
-
Alan Coopersmith authored
If the X server returns key indexes outside the range of the number of keys it told us to allocate, out of bounds memory writes could occur. Reported-by:
-
Alan Coopersmith authored
If the X server returns modifier map indexes outside the range of the number of keys it told us to allocate, out of bounds memory writes could occur. Reported-by:
-
Alan Coopersmith authored
If the X server returns key behavior indexes outside the range of the number of keys it told us to allocate, out of bounds memory writes could occur. Reported-by:
-
Alan Coopersmith authored
If the X server returns key action indexes outside the range of the number of keys it told us to allocate, out of bounds memory access could occur. Reported-by:
-
Alan Coopersmith authored
If the X server returns keymap indexes outside the range of the number of keys it told us to allocate, out of bounds memory access could occur. Reported-by:
-
Alan Coopersmith authored
If the X server returns color indexes outside the range of the number of colors it told us to allocate, out of bounds memory access could occur. Reported-by:
-
Alan Coopersmith authored
If the X server returns shape indexes outside the range of the number of shapes it told us to allocate, out of bounds memory access could occur. Reported-by:
-
Alan Coopersmith authored
If the X server returns more buttons than are allocated in the XKB device info structures, out of bounds writes could occur. Reported-by:
-
Alan Coopersmith authored
If a broken server returned larger than requested values for nPixels or nMasks, XAllocColorCells would happily overflow the buffers provided by the caller to write the results into. Reported-by:
-
Alan Coopersmith authored
Avoids memory corruption and other errors when callers access them without checking to see if XGetWindowProperty() returned an error value. Callers are still required to check for errors, this just reduces the damage when they don't. Reported-by:
-
Alan Coopersmith authored
Lets stop duplicating the mess all over Signed-off-by:
-
