Checking against upper limit of USHRT_MAX must happen before truncating
size_t to int. On 64 bit systems with strings larger than 2 GB this
could otherwise lead to negative ints or ints smaller than USHRT_MAX.

In XParseColor this could lead to out of boundary access with strings
starting with a # (color sequence). A modulo 12 operation is performed
to validate the string length, but with an overflown length, the for
loop would eventually read behind terminating '\0' character.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

Problem reported by Karsten Trulsen

Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>

The X protocol uses CARD16 values to represent the length so
this would overflow.

CVE-2021-31535

Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>

Signed-off-by: Thomas E. Dickey <dickey@invisible-island.net>

Fernando Carrijo authored 14 years ago and Alan Coopersmith committed 14 years ago

Signed-off-by: Fernando Carrijo <fcarrijo@yahoo.com.br>
Acked-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>

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

Disable large tracts of colour management code when passing
--disable-xcms.

- For Xcomposite and Xdamage, don't link the build system out of the xc tree
- Link the public X11 headers into their own directory
- Add links to XKeysymDB and XErrorDB
- Add links to all the Xlib man pages
- Add links to the lcUniConv subdirectory
- Conditionally include config.h in Xlib source