An integer overflow in the validation of the parameters of the
ShmPutImage() request makes it possible to trigger the copy of
arbitrary server memory to a pixmap that can subsequently be read by
the client, to read arbitrary parts of the X server memory space.
Lack of validation of the parameters of the
SProcSecurityGenerateAuthorization SProcRecordCreateContext
functions makes it possible for a specially crafted request to trigger
the swapping of bytes outside the parameter of these requests, causing
memory corruption.
Integer overflows can occur in the code validating the parameters for
the SProcRenderCreateLinearGradient, SProcRenderCreateRadialGradient
and SProcRenderCreateConicalGradient functions, leading to memory
corruption by swapping bytes outside of the intended request
parameters.
An integer overflow may occur in the computation of the
size of the glyph to be allocated by the ProcRenderCreateCursor()
function which will cause less memory to be allocated than expected,
leading later to dereferencing un-mapped memory, causing a crash of
the X server.
An integer overflow may occur in the computation of the size of the
glyph to be allocated by the AllocateGlyph() function which will cause
less memory to be allocated than expected, leading to later heap
overflow.
On systems where the X SIGSEGV handler includes a stack trace, more
malloc()-type functions are called, which may lead to other
exploitable issues.
ProcessOtherEvents was unconditionally stomping the root_{x,y}
co-ordinates provided by GetPointerEvents with those of the core
pointer, meaning that both root_{x,y} and event_{x,y} reported to
clients would reflect the sprite's position, not the position reported
by the device that generated the DeviceMotionNotify or the
DeviceButton{Press,Release} event in the first place.
For key events we still take the sprite's co-ords, as we're delivering
to the focus, which is the (VCP) sprite.
Not cherry-picked from master as MPX fixes this anyway, by taking the
co-ords of the sprite the device moves (be it visible or no).
(cherry picked from commit 8259d19f71)
It actually does help if a pointer is NULL rather than pointing to nirvana
when you're trying to free it lateron. Who would have thought?
(cherry picked from commit 7a97ca667405a42d008265c3a870210cc1da97dd)
(cherry picked from commit 0b0a097973)
(cherry picked from commit ab9b0b36ac)
(cherry picked from commit 4fa89fbe18)
... and backported to 1.4 (back to no new devprivates and "amd" driver name)
