- 19 Oct, 2016 15 commits
-
-
Erkki Seppälä authored
The NEWTABLE macro missed freeing its allocated memory on subsequent memory allocation errors. Added call to Xfree. Variable "table" goes out of scope Reviewed-by:
Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by:
Ander Conselvan de Oliveira <ander.conselvan-de-oliveira@nokia.com> Signed-off-by:
Erkki Seppälä <erkki.seppala@vincit.fi> Signed-off-by:
Ulrich Sibiller <uli42@gmx.de>
-
Erkki Seppälä authored
Fixed memory leak by adding Xfree for image Variable "image" goes out of scope Reviewed-by:
-
Erkki Seppälä authored
Using uninitialized value "new" Reviewed-by:
-
Erkki Seppälä authored
Pointer "pBuf" returned from "fgets(buf, 256, stream)" is never used Reviewed-by:
-
Alan Coopersmith authored
Instead of copying the value returned by get_prop_name and then releasing it, directly use the return value of get_prop_name, which allocates memory for the name. If get_prop_name returns NULL, continue on to XFreeFont to release the font before returning the NULL via the normal function return. Reviewed-by:
-
Erkki Seppälä authored
Removed superfluous comparison. Reviewed-by:
Dirk Wallenstein <halsmit@t-online.de> Signed-off-by:
-
Erkki Seppälä authored
Check entry for non-nullness before dereferencing it Reviewed-by:
-
Erkki Seppälä authored
Dereferencing possibly NULL "str" in call to function "memcpy" (Deref assumed on the basis of 'nonnull' parameter attribute.) If _XkbGetReadBufferPtr returns NULL, goto BAILOUT Reviewed-by:
-
Erkki Seppälä authored
Reordered code to first to do the comparison and then to release data Reviewed-by:
-
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:
-
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: -
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 14 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:
-
