GitLab

Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Signed-off-by: Mihail Konev <k.mvc@ya.ru>

Place quotes around the $srcdir, $ORIGDIR and $0 variables to prevent
fall-outs, when they contain space.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Syncs the invocation of configure with the one from the server.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

If the compiler knows of a better algorithm for counting the number of
bits set in a word for the target CPU, let it use that, instead of the
classic algorithm optimized for PDP-6.

Tested for the range of values used in XSecurity.c and verified results
are the same from both:

for (unsigned long i = 0; i <= XSecurityAllAuthorizationAttributes; i++) {
    printf("ones: %d\tpopcnt: %d\n", Ones(i), __builtin_popcountl(i));
}
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Catch if anyone ever defines more types again and forgets to increase
the size of the value buffer to match.

v2: assert on the full set of possible values, regardless of which the
    current caller passed in this call - more likely to be spotted during
    testing, less likely to not be found until called in production.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

https://bugs.freedesktop.org/show_bug.cgi?id=94292Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Seth Arnold <seth.arnold@canonical.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

When mixing Xlib and xcb, it's quite possible for some events to be
received for xcb-only extensions, which will subsequently not be
translatable by the Xge WireToEvent/EventToWire hooks
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

evi_return is passed in as a pointer to a location into which
XeviGetVisualInfo is expected to write a pointer to the memory
it allocated for the returned structures.  If we're failing and
bailing out, we need to dispose of the pointer we set, not the
one passed into us (which the caller may have put on the stack
or allocated as part of a larger structure).

Flagged by cppcheck 1.64:
[lib/libXext/src/XEVI.c:182] -> [lib/libXext/src/XEVI.c:186]:
 (warning) Possible null pointer dereference: evi_return - otherwise it
           is redundant to check it against null.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

A malicious X server claiming to not support GE but sending a GE would
SEGV the client  (always a NULL derefrence).  Possible since d1c93500.

(Also guard the EventToWire case so it's harder to shoot yourself in the
foot.)
Signed-off-by: Nathan Kidd <nkidd@opentext.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

_XEatDataWords was orignally introduced with the May 2013 security
patches, and in order to ease the process of delivering those,
fallback versions of _XEatDataWords were included in the X extension
library patches so they could be applied to older versions that didn't
have libX11 1.6 yet.   Now that we're past that hurdle, we can drop
the fallbacks and just require libX11 1.6 for building new versions
of the extension libraries.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

If the number of counters or amount of data reported by the server is
large enough that it overflows when multiplied by the size of the
appropriate struct, then memory corruption can occur when more bytes
are read from the X server than the size of the buffers we allocated
to hold them.

V2: Make sure we don't walk past the end of the reply when converting
data from wire format to the structures returned to the caller.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

If the number of rectangles reported by the server is large enough that
it overflows when multiplied by the size of the appropriate struct, then
memory corruption can occur when more bytes are read from the X server
than the size of the buffer we allocated to hold them.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

If the number of visuals or conflicts reported by the server is large
enough that it overflows when multiplied by the size of the appropriate
struct, then memory corruption can occur when more bytes are read from
the X server than the size of the buffer we allocated to hold them.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

If the number of screens or visuals reported by the server is large enough
that it overflows when multiplied by the size of the appropriate struct,
then memory corruption can occur when more bytes are read from the X server
than the size of the buffer we allocated to hold them.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

If the computed number of entries is large enough that it overflows when
multiplied by the size of a xColorItem struct, or is treated as negative
when compared to the size of the stack allocated buffer, then memory
corruption can occur when more bytes are read from the X server than the
size of the buffer we allocated to hold them.

The requirement to match the number of colors specified by the caller makes
this much harder to hit than the one in XcupGetReservedColormapEntries()
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

If the computed number of entries is large enough that it overflows when
multiplied by the size of a xColorItem struct, or is treated as negative
when compared to the size of the stack allocated buffer, then memory
corruption can occur when more bytes are read from the X server than the
size of the buffer we allocated to hold them.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

rep.length is a CARD32, so rep.length << 2 could overflow in 32-bit builds
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

http://people.gnome.org/~walters/docs/build-api.txtSigned-off-by: Adam Jackson <ajax@redhat.com>

Signed-off-by: Adam Jackson <ajax@redhat.com>

This will assist translation to DocBook.
Signed-off-by: Eric S. Raymond <esr@thyrsus.com>

These can be translated structurally into DocBook.

From Matthew R. Green <mrg@NetBSD.org>
Signed-off-by: Thomas Klausner <wiz@NetBSD.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

The extension record is currently leaked and never freed.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

#1 - fix the capitolization of the ID attriutes to match either
     the <title> or <funcdef> string it goes with.
#2 - fix any <linkend>'s that were affected by #1
#3 - any <function> in the docs that has an actual funcdef, will
     become an olink.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Some elements are not displayed when outside authorgroup
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>

Signed-off-by: Gaetan Nadon <memsize@videotron.ca>