- 12 Oct, 2016 39 commits
-
-
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 <alan.coopersmith@oracle.com> Signed-off-by:
Julien Cristau <jcristau@debian.org> Backported-to-NX-by:
Ulrich Sibiller <uli42@gmx.de>
-
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:
Matthieu Herrb <matthieu.herrb@laas.fr> 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:
-
Alan Coopersmith authored
Signed-off-by:
-
Alan Coopersmith authored
Ensure that we don't underallocate when the server claims a very large reply Signed-off-by:
-
Alan Coopersmith authored
Ensure that we don't underallocate when the server claims a very large reply Signed-off-by:
-
Alan Coopersmith authored
Ensure that we don't underallocate when the server claims to have sent a very large reply. Signed-off-by:
-
Alan Coopersmith authored
If the reported number of properties is too large, the calculations to allocate memory for them may overflow, leaving us returning less memory to the caller than implied by the value written to *nitems. Reported-by:
-
Alan Coopersmith authored
When trying to process file paths the tokens %H, %L, & %S are expanded to $HOME, the standard compose file path & the xlocaledir path. If enough of these tokens are repeated and values like $HOME are set to very large values, the calculation of the total string size required to hold the expanded path can overflow, resulting in allocating a smaller string than the amount of data we'll write to it. Simply restrict all of these values, and the total path size to PATH_MAX, because really, that's all you should need for a filename path. Reported-by:
-
Alan Coopersmith authored
Called from _XimCreateDefaultTree() which uses getenv("XCOMPOSEFILE") to specify filename. If the size of off_t is larger than the size of unsigned long (as in 32-bit builds with large file flags), a file larger than 4 gigs could have its size truncated, leading to data from that file being written past the end of the undersized buffer allocated for it. While configure.ac does not use AC_SYS_LARGEFILE to set large file mode, builders may have added the large file compilation flags to CFLAGS on their own. size is left limited to an int, because if your Xim file is larger than 2gb, you're doing it wrong. Reported-by: -
Alan Coopersmith authored
Called from XrmGetFileDatabase() which gets called from InitDefaults() which gets the filename from getenv ("XENVIRONMENT") If file is exactly 0xffffffff bytes long (or longer and truncates to 0xffffffff, on implementations where off_t is larger than an int), then size may be set to a value which overflows causing less memory to be allocated than is written to by the following read() call. size is left limited to an int, because if your Xresources file is larger than 2gb, you're very definitely doing it wrong. Reported-by: -
Alan Coopersmith authored
Integer overflows in stringSectionSize() cause buffer overflow in ReadColornameDB() [CVE-2013-1981 6/13] LoadColornameDB() calls stringSectionSize() to do a first pass over the file (which may be provided by the user via XCMSDB environment variable) to determine how much memory needs to be allocated to read in the file, then allocates the returned sizes and calls ReadColornameDB() to load the data from the file into that newly allocated memory. If stringSectionSize() overflows the signed ints used to calculate the file size (say if you have an xcmsdb with ~4 billion lines in or a combined string length of ~4 gig - which while it may have been inconceivable when Xlib was written, is quite possible today), then LoadColornameDB() may allocate a memory buffer much smaller than the amount of data ReadColornameDB() will write to it. The total size is left limited to an int, because if your xcmsdb file is larger than 2gb, you're doing it wrong. Reported-by:
-
Alan Coopersmith authored
If the reported number of host entries is too large, the calculations to allocate memory for them may overflow, leaving us writing beyond the bounds of the allocation. Reported-by:
-
Alan Coopersmith authored
If the reported number of motion events is too large, the calculations to allocate memory for them may overflow, leaving us writing beyond the bounds of the allocation. v2: Ensure nEvents is set to 0 when returning NULL events pointer Reported-by:
-
Alan Coopersmith authored
If the reported number of remaining fonts is too large, the calculations to allocate memory for them may overflow, leaving us writing beyond the bounds of the allocation. v2: Fix reply_left calculations, check calculated sizes fit in reply_left v3: On error cases, also set values to be returned in pointer args to 0/NULL Reported-by:
-
Alan Coopersmith authored
Similar to _XQueryFont, but with more ways to go wrong and overflow. Only compiled if libX11 is built with XF86BigFont support. v2: Fix reply_left calculations, check calculated sizes fit in reply_left Reported-by:
-
Alan Coopersmith authored
If the CARD32 reply.nCharInfos * sizeof(XCharStruct) overflows an unsigned long, then too small of a buffer will be allocated for the data copied in from the reply. v2: Fix reply_left calculations, check calculated sizes fit in reply_left Reported-by:
-
Nickolai Zeldovich authored
If exactly one of the two reallocs in XListFontsWithInfo() fails, the subsequent code accesses memory freed by the other realloc. Signed-off-by:
Nickolai Zeldovich <nickolai@csail.mit.edu> Reviewed-by:
-
Alan Coopersmith authored
In the highly unlikely event that TransFileName was passed a path containing multiple %L entries, for each entry it would call _XlcFileName, leaking the previous results, and then for each entry it would copy from that pointer and free it, resulting in invalid pointers & possible double frees for each use after the first one freed it. Error: Use after free (CWE 416) Use after free of pointer 'lcCompose' at line 358 of nx-X11/lib/X11/imLcPrs.c in function 'TransFileName'. Previously freed at line 360 with free. Error: Use after free (CWE 416) Use after free of pointer 'lcCompose' at line 359 of nx-X11/lib/X11/imLcPrs.c in function 'TransFileName'. Previously freed at line 360 with free. Error: Double free (CWE 415) Double free of pointer 'lcCompose' at line 360 of nx-X11/lib/X11/imLcPrs.c in function 'TransFileName'. Previously freed at line 360 with free. [ This bug was found by the Parfait 0.3.6 bug checking tool. For more information see http://labs.oracle.com/projects/parfait/ ] Signed-off-by: -
Erkki Seppälä authored
Tracked variable "size" was passed to a negative sink. 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:
-
Mike Gabriel authored
Attributes GH PR #214: https://github.com/ArcticaProject/nx-libs/pull/214 Fixes ArcticaProject/nx-libs#157.
-
- 10 Oct, 2016 1 commit
-
-
Ulrich Sibiller authored
Imake unsets __APPLE__ and sets __DARWIN__ instead while autoconf seems to use __APPLE__ and not __DARWIN__ anymore. This way we should stay safe for now. Can be changed to __APPLE__ when we switch to modular.
-
