aboutsummaryrefslogtreecommitdiff
path: root/nx-X11/lib
Commit message (Collapse)AuthorAgeFilesLines
* Make XGetWindowProperty() always initialize returned valuesAlan Coopersmith2016-10-121-1/+7
| | | | | | | | | | | | | | 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: Ilja Van Sprundel <ivansprundel@ioactive.com> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Matthieu Herrb <matthieu.herrb@laas.fr> Signed-off-by: Julien Cristau <jcristau@debian.org> Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
* Move repeated #ifdef magic to find PATH_MAX into a common headerAlan Coopersmith2016-10-124-48/+85
| | | | | | | | | Lets stop duplicating the mess all over Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Matthieu Herrb <matthieu.herrb@laas.fr> Signed-off-by: Julien Cristau <jcristau@debian.org> Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
* Convert more _XEatData callers to _XEatDataWordsAlan Coopersmith2016-10-126-20/+20
| | | | | | | Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Matthieu Herrb <matthieu.herrb@laas.fr> Signed-off-by: Julien Cristau <jcristau@debian.org> Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
* integer overflow in XGetModifierMapping() [CVE-2013-1981 13/13]Alan Coopersmith2016-10-121-4/+9
| | | | | | | | | Ensure that we don't underallocate when the server claims a very large reply Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Matthieu Herrb <matthieu.herrb@laas.fr> Signed-off-by: Julien Cristau <jcristau@debian.org> Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
* integer overflow in XGetPointerMapping() & XGetKeyboardMapping() ↵Alan Coopersmith2016-10-121-11/+20
| | | | | | | | | | | [CVE-2013-1981 12/13] Ensure that we don't underallocate when the server claims a very large reply Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Matthieu Herrb <matthieu.herrb@laas.fr> Signed-off-by: Julien Cristau <jcristau@debian.org> Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
* integer overflow in XGetImage() [CVE-2013-1981 11/13]Alan Coopersmith2016-10-121-4/+8
| | | | | | | | | | Ensure that we don't underallocate when the server claims to have sent a very large reply. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Matthieu Herrb <matthieu.herrb@laas.fr> Signed-off-by: Julien Cristau <jcristau@debian.org> Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
* integer overflow in XGetWindowProperty() [CVE-2013-1981 10/13]Alan Coopersmith2016-10-121-9/+16
| | | | | | | | | | | | 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: Ilja Van Sprundel <ivansprundel@ioactive.com> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Matthieu Herrb <matthieu.herrb@laas.fr> Signed-off-by: Julien Cristau <jcristau@debian.org> Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
* integer overflows in TransFileName() [CVE-2013-1981 9/13]Alan Coopersmith2016-10-121-11/+34
| | | | | | | | | | | | | | | | | | 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: Ilja Van Sprundel <ivansprundel@ioactive.com> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Matthieu Herrb <matthieu.herrb@laas.fr> Signed-off-by: Julien Cristau <jcristau@debian.org> Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
* integer truncation in _XimParseStringFile() [CVE-2013-1981 8/13]Alan Coopersmith2016-10-121-0/+3
| | | | | | | | | | | | | | | | | | | | | | | 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: Ilja Van Sprundel <ivansprundel@ioactive.com> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Matthieu Herrb <matthieu.herrb@laas.fr> Signed-off-by: Julien Cristau <jcristau@debian.org> Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
* integer overflow in ReadInFile() in Xrm.c [CVE-2013-1981 7/13]Alan Coopersmith2016-10-121-1/+3
| | | | | | | | | | | | | | | | | | | 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: Ilja Van Sprundel <ivansprundel@ioactive.com> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Matthieu Herrb <matthieu.herrb@laas.fr> Signed-off-by: Julien Cristau <jcristau@debian.org> Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
* Integer overflows in stringSectionSize() cause buffer overflow in ↵Alan Coopersmith2016-10-121-6/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: Ilja Van Sprundel <ivansprundel@ioactive.com> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Matthieu Herrb <matthieu.herrb@laas.fr> Signed-off-by: Julien Cristau <jcristau@debian.org> Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
* integer overflow in XListHosts() [CVE-2013-1981 5/13]Alan Coopersmith2016-10-121-7/+15
| | | | | | | | | | | | 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: Ilja Van Sprundel <ivansprundel@ioactive.com> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Matthieu Herrb <matthieu.herrb@laas.fr> Signed-off-by: Julien Cristau <jcristau@debian.org> Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
* integer overflow in XGetMotionEvents() [CVE-2013-1981 4/13]Alan Coopersmith2016-10-121-15/+11
| | | | | | | | | | | | | 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: Ilja Van Sprundel <ivansprundel@ioactive.com> 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>
* integer overflow in XListFontsWithInfo() [CVE-2013-1981 3/13]Alan Coopersmith2016-10-121-56/+49
| | | | | | | | | | | | | | 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: Ilja Van Sprundel <ivansprundel@ioactive.com> 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>
* integer overflow in _XF86BigfontQueryFont() [CVE-2013-1981 2/13]Alan Coopersmith2016-10-121-17/+25
| | | | | | | | | | | | 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: Ilja Van Sprundel <ivansprundel@ioactive.com> 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>
* integer overflow in _XQueryFont() on 32-bit platforms [CVE-2013-1981 1/13]Alan Coopersmith2016-10-121-12/+25
| | | | | | | | | | | | | 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: Ilja Van Sprundel <ivansprundel@ioactive.com> 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>
* XListFontsWithInfo: avoid accessing realloc'ed memoryNickolai Zeldovich2016-10-121-6/+7
| | | | | | | | | | | | | 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 <alan.coopersmith@oracle.com> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> (cherry picked from commit deedeada53676ee529d700bf96fde0b29a3a1def) Signed-off-by: Julien Cristau <jcristau@debian.org> Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
* ximcp: Prevent memory leak & double free if multiple %L in stringAlan Coopersmith2016-10-121-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Alan Coopersmith <alan.coopersmith@oracle.com> (cherry picked from commit 6ac417cea1136a3617f5e40f4b106aaa3f48d6c2) Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
* Xrm: Handle the extremely unlikely situation of fstat failingErkki Seppälä2016-10-121-0/+6
| | | | | | | | | | | Tracked variable "size" was passed to a negative sink. 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: Alan Coopersmith <alan.coopersmith@oracle.com> (cherry picked from commit be3e6c205d94dedc1cdebf5d17b987f0f828377a) Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
* Use both __APPLE__ and __DARWIN__ definesUlrich Sibiller2016-10-102-3/+3
| | | | | | | | 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.
* MakeBigReq: don't move the last word, already handled by Data32 (X.Org ↵Karl Tomlinson2016-10-101-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | CVE-2013-7439). MakeBigReq inserts a length field after the first 4 bytes of the request (after req->length), pushing everything else back by 4 bytes. The current memmove moves everything but the first 4 bytes back. If a request aligns to the end of the buffer pointer when MakeBigReq is invoked for that request, this runs over the buffer. Instead, we need to memmove minus the first 4 bytes (which aren't moved), minus the last 4 bytes (so we still align to the previous tail). The 4 bytes that fell out are already handled with Data32, which will handle the buffermax correctly. The case where req->length = 1 was already not functional. Reported by Abhishek Arya <inferno@chromium.org> (against X.Org BTS). https://bugzilla.mozilla.org/show_bug.cgi?id=803762 Reviewed-by: Jeff Muizelaar <jmuizelaar@mozilla.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Rebased-for-NX: Mike Gabriel <mike.gabriel@das-netzwerkteam.de> Re-applied after upgrade to libX11 1.3.4: Ulrich Sibiller <uli42@gmx.de>
* Give GNU & Solaris Studio compilers hints about XEatData branchesAlan Coopersmith2016-10-101-2/+14
| | | | | | | | Try to offset the cost of all the recent checks we've added by giving the compiler a hint that the branches that involve us eating data are less likely to be used than the ones that process it. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
* makekeys: move buf declaration from global to main to silence gcc -WshadowAlan Coopersmith2016-10-101-1/+1
| | | | | | | | | | | | The global was only referenced in the main() function, which passes it as an argument of the same name to the parse_line() function, leading to gcc -Wshadow warnings: makekeys.c: In function ‘parse_line’: makekeys.c:58:24: warning: declaration of ‘buf’ shadows a global declaration makekeys.c:54:13: warning: shadowed declaration is here Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
* makekeys: Fix build/target word size mismatch when cross-compilingDerek Buitenhuis2016-10-103-5/+7
| | | | | | | | | | | | | | | Since makekeys is built using build environment's gcc and runs natively, we have to make sure that the size of the Signature type is the same on both the native environment and the target, otherwise we get mismatches upon running X, and some LSB test failures (xts5). Use an unsigned 32-bit integer on all platforms. Also, eliminate the redundant multiple typedefs for the Signature type. Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com> Reviewed-by: Daniel Stone <daniel@fooishbar.org>
* adapt Imakefile to call makekeys correctly after updateUlrich Sibiller2016-10-101-2/+3
| | | | makekeys expects filenames as arguments instead of stdin
* makekeys: Scan vendor keysyms as well as coreDaniel Stone2016-10-101-44/+83
| | | | | | | | | Since we can't really live without vendor keysyms, scan them all in to generate ks_tables.h, rather than only doing the core ones, and leaving the vendor syms to be manually synchronised with XKeysymDB. Signed-off-by: Daniel Stone <daniel@fooishbar.org> Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
* When makekeys fails to find a good hash, print error instead of divide-by-zeroAlan Coopersmith2016-10-101-0/+10
| | | | Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
* Increase size of working arrays in the makekeys utility program.James Cloos2016-10-101-1/+1
| | | | | | | | | | | | | | | | | | | Makekeys is used to create an optimal hash of the keysyms defined in x11proto’s keysymdef.h. The recent addition of new keysyms there has triggered a bug in makekeys where it tries to use a zero on the rhs of the % (mod) operator (resulting in a divide by zero error) whenever it fails to find a solution within its constraints. Increasing the size of the arrays allows it to find a solution for the current set of keysyms. Makekeys is only run durring the build process, so this has no impact on users of libX11, only on the amount of VM needed to build it. It still needs a more complete fix, but this allows compiles to progress until that is completed.
* update files from modules dir of libX11 1.3.4Ulrich Sibiller2016-10-1037-1020/+1694
|
* Xutil.h: Fix wrong include pathUlrich Sibiller2016-10-101-1/+1
|
* replace {x11,xim}trans.c links by libX11 1.3.4 solutionUlrich Sibiller2016-10-103-10/+68
|
* update xlibi18n files to libX11 1.3.4Ulrich Sibiller2016-10-1038-475/+1224
|
* update xcms files to libX11 1.3.4Ulrich Sibiller2016-10-1064-710/+823
|
* Update some missing files to libX11 1.3.4Ulrich Sibiller2016-10-106-27/+27
|
* Add (Free|Get)EventData.c from libX11 1.3.4Ulrich Sibiller2016-10-103-0/+88
|
* remove more NEED_REPLIES/EVENTSUlrich Sibiller2016-10-103-3/+0
|
* Purge more remaining VCS refsUlrich Sibiller2016-10-1033-34/+0
|
* Lift XKB*.c to libX11 1.3.4Ulrich Sibiller2016-10-1021-288/+326
|
* XlibInt.c: shorten one ifdefUlrich Sibiller2016-10-101-1/+1
|
* set USE_XCB define to 0 to prevent compiler complaintsUlrich Sibiller2016-10-101-1/+2
|
* Remove CRAY supportUlrich Sibiller2016-10-104-317/+0
| | | | | This basically repeats commit bad67799229b94ea2ba0174319949766ad1c2fc6 after the upgrade to libX11 1.3.4.
* adapt include files to libX11 1.3.4Ulrich Sibiller2016-10-105-47/+48
|
* update makekeys.c to libX11 1.3.4 (+ fix)Ulrich Sibiller2016-10-101-11/+7
|
* update lcUniConv subdir to libX11 1.3.4Ulrich Sibiller2016-10-1032-34/+12506
|
* update src files *[ch] to libX11 1.3.4Ulrich Sibiller2016-10-10238-2503/+2532
|
* add XLOCALELIBDIRUlrich Sibiller2016-10-101-1/+1
|
* improve header guardsUlrich Sibiller2016-10-1010-20/+34
| | | | Upstream has changed the header guards. We adapt them to prevent double inclusion.
* update all files with NX relevant changes to libX11 1.3.4Ulrich Sibiller2016-10-1017-620/+1760
|
* fix wrong include in XlibInt.cUlrich Sibiller2016-10-091-1/+1
|
* Add XF86TouchpadOn and XF86TouchpadOff to keysymdbPeter Hutterer2016-10-011-0/+2
| | | | | | | This patch isn't necessary in Xlib 1.4 and later since the keysymdb has been made redunant. While we're on 1.3.x, we need it. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-08 23:54:28 +0000