Due to C arithmetic conversion rules we must use an unsigned constant (or a
 cast) to perform the multiplication using unsigned arithmetic.

 Fixes ArcticaProject/nx-libs#55.

 Author: Emanuele Giaquinta <emanuele.giaquinta@gmail.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
 Rebased against NX: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

 The client-side library libNX_GL.{a,so} is not built when building nx-libs.

 However, nx-X11/lib/GL/** ships several imake include files
 (Imakefile.inc) that are also used in nx-X11/programs/Xserver/GL/**.
 These files have been moved from the nx-X11/lib/GL/ code subtree to the
 nx-X11/programs/Xserver/GL/.

 Furthermore, we don't provide module builds of the GL extension anymore,
 as that feature is neither used in nx-libs.

library clean-up: Don't build libNX_Xdamage anymore. Use system's libXdamage shared library. (Fixes ArcticaProject/nx-libs#6, X2GoBTS#826).

imake cleanup: Break up multiple vars into invidual lines to ease further work on patches / pull requests.

library clean-up: Don't build and link libXfont.a anymore. Use system's libXfont shared library and link dynamically.

 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=803762Reviewed-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>

old-arch cleanup: Drop CRAY support (i.e., drop code related to CRAY, _CRAY, WORD64, WORD64ALIGN, MUSTCOPY, UNSIGNEDBITFIELDS definitions).

It ensures that all valid input can be decompressed, checks that the
overflow conditions doesn't happen and generally tightens the
validation of the LZW stream and doesn't pessimize the inner loop for
no good reason. It's derived from a change in libarchive from 2004.

v2: backports to nx-libs 3.6.x (Mihai Moldovan)
v3: fix comment lines starting with "+" + whitespace fixes (Mike Gabriel)
Signed-off-by: Matthieu Herrb <matthieu.herrb@laas.fr>
Reviewed-by: Tomas Hoger <thoger@redhat.com>

This reverts commit 6acafc93.

It ensures that all valid input can be decompressed, checks that the
overflow conditions doesn't happen and generally tightens the
validation of the LZW stream and doesn't pessimize the inner loop for
no good reason. It's derived from a change in libarchive from 2004.

v2: backports to nx-libs 3.6.x (Mihai Moldovan)
Signed-off-by: Matthieu Herrb <matthieu.herrb@laas.fr>
Reviewed-by: Tomas Hoger <thoger@redhat.com>

CVE-2014-0210: unvalidated length in _fs_recv_conn_setup() from xorg/lib/libXfont commit 891e084b26837162b12f841060086a105edde86d

The connection setup reply from the font server can include a list
of alternate servers to contact if this font server stops working.

The reply specifies a total size of all the font server names, and
then provides a list of names. _fs_recv_conn_setup() allocated the
specified total size for copying the names to, but didn't check to
make sure it wasn't copying more data to that buffer than the size
it had allocated.

v2: use xfree() instead of free() for nx-libs 3.6.x (Mihai Moldovan)

Revert "CVE-2014-0210: unvalidated length in _fs_recv_conn_setup() from xorg/lib/libXfont commit 891e084b26837162b12f841060086a105edde86d"

This reverts commit 94c6de06.

CVE-2014-0210: unvalidated length fields in fs_read_query_info() from xorg/lib/libXfont commit 491291cabf78efdeec8f18b09e14726a9030cc8f

fs_read_query_info() parses a reply from the font server.  The reply
contains embedded length fields, none of which are validated.  This
can cause out of bound reads in either fs_read_query_info() or in
_fs_convert_props() which it calls to parse the fsPropInfo in the reply.

v2: apply correctly on nx-libs 3.6.x (Mihai Moldovan)

Revert "CVE-2014-0210: unvalidated length fields in fs_read_query_info() from xorg/lib/libXfont commit 491291cabf78efdeec8f18b09e14726a9030cc8f"

This reverts commit c6aebf92.

CVE-2014-0210: unvalidated length fields in fs_read_list_info() from xorg/lib/libXfont commit d338f81df1e188eb16e1d6aeea7f4800f89c1218

fs_read_list_info() parses a reply from the font server.  The reply
contains a number of additional data items with embedded length or
count fields, none of which are validated. This can cause out of
bound reads when looping over these items in the reply.

CVE-2014-0210: unvalidated length fields in fs_read_list() from xorg/lib/libXfont commit 5fa73ac18474be3032ee7af9c6e29deab163ea39

fs_read_list() parses a reply from the font server.  The reply
contains a list of strings with embedded length fields, none of
which are validated. This can cause out of bound reads when looping
over the strings in the reply.

CVE-2014-0210: unvalidated length fields in fs_read_glyphs() from xorg/lib/libXfont commit 520683652564c2a4e42328ae23eef9bb63271565

fs_read_glyphs() parses a reply from the font server.  The reply
contains embedded length fields, none of which are validated.
This can cause out of bound reads when looping over the glyph
bitmaps in the reply.

CVE-2014-0210: unvalidated length fields in fs_read_extent_info() from xorg/lib/libXfont commit a3f21421537620fc4e1f844a594a4bcd9f7e2bd8

Looping over the extents in the reply could go past the end of the
reply buffer if the reply indicated more extents than could fit in
the specified reply length.

CVE-2014-0211: integer overflow in fs_alloc_glyphs() from xorg/lib/libXfont commit a42f707f8a62973f5e8bbcd08afb10a79e9cee33

fs_alloc_glyphs() is a malloc wrapper used by the font code.
It contains a classic integer overflow in the malloc() call,
which can cause memory corruption.

CVE-2014-0211: integer overflow in fs_read_extent_info() from xorg/lib/libXfont commit c578408c1fd4db09e4e3173f8a9e65c81cc187c1

fs_read_extent_info() parses a reply from the font server.
The reply contains a 32bit number of elements field which is used
to calculate a buffer length. There is an integer overflow in this
calculation which can lead to memory corruption.

CVE-2014-0210: unvalidated length fields in fs_read_query_info() from xorg/lib/libXfont commit 491291cabf78efdeec8f18b09e14726a9030cc8f

fs_read_query_info() parses a reply from the font server.  The reply
contains embedded length fields, none of which are validated.  This
can cause out of bound reads in either fs_read_query_info() or in
_fs_convert_props() which it calls to parse the fsPropInfo in the reply.

CVE-2014-0211: Integer overflow in fs_get_reply/_fs_start_read from xorg/lib/libXfont commit 0f1a5d372c143f91a602bdf10c917d7eabaee09b

fs_get_reply() would take any reply size, multiply it by 4 and pass to
_fs_start_read.  If that size was bigger than the current reply buffer
size, _fs_start_read would add it to the existing buffer size plus the
buffer size increment constant and realloc the buffer to that result.

This math could overflow, causing the code to allocate a smaller
buffer than the amount it was about to read into that buffer from
the network.  It could also succeed, allowing the remote font server
to cause massive allocations in the X server, possibly using up all
the address space in a 32-bit X server, allowing the triggering of
other bugs in code that fails to handle malloc failure properly.

This patch protects against both problems, by disconnecting any
font server trying to feed us more than (the somewhat arbitrary)
64 mb in a single reply.