| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: Ulrich Sibiller <uli42@gmx.de>
|
|
|
|
|
|
|
|
|
| |
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: Ulrich Sibiller <uli42@gmx.de>
|
|
|
|
|
|
| |
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
|
|
|
|
|
|
|
|
|
|
| |
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 <daniel@fooishbar.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
|
|
|
|
|
|
|
|
|
|
| |
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: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
|
|
|
|
|
|
| |
glcontextmodes.c not being compiled.
The typo didn't cause immediate problems.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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: Alan Coopersmith <alan.coopersmith@oracle.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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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 <alan.coopersmith@oracle.com>
Signed-off-by: Julien Cristau <jcristau@debian.org>
Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[CVE-2013-2004 2/2]
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 <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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[CVE-2013-2004 1/2]
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: 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>
|
|
|
|
|
|
|
|
|
|
| |
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 <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>
|
|
|
|
|
|
|
|
|
|
| |
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 <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>
|
|
|
|
|
|
|
|
|
|
| |
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 <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>
|
|
|
|
|
|
|
|
|
|
|
| |
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: 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>
|
|
|
|
|
|
|
|
|
|
|
| |
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: 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>
|
|
|
|
|
|
|
|
|
|
|
| |
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: 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>
|
|
|
|
|
|
|
|
|
|
|
| |
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: 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>
|
|
|
|
|
|
|
|
|
|
|
| |
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: 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>
|
|
|
|
|
|
|
|
|
|
|
| |
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: 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>
|
|
|
|
|
|
|
|
|
|
|
| |
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: 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>
|
|
|
|
|
|
|
|
|
|
|
| |
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: 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>
|
|
|
|
|
|
|
|
|
|
|
| |
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: 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>
|
|
|
|
|
|
|
|
|
|
|
| |
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: 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>
|
|
|
|
|
|
|
|
|
|
|
| |
If the X server returns more buttons than are allocated in the XKB
device info structures, out of bounds writes could occur.
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
[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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|