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)
The -wm (when mapped) option for the BackingStore support has been
causing the server to dereference a NULL pointer.
This has probably been the case since backing store has been
implemented on top of Composite.
It looks like (some of?) Composite didn’t expect its WIndowPtr
argument to be the root window.
In Composite’s compCheckRedirect() function we now avoid calling
compAllocPixmap() and compFreePixmap() when the pWin pointer’s
parent member is NULL, as is it the case with a server’s root window.
This addresses:
https://bugs.freedesktop.org/show_bug.cgi?id=15878
(cherry picked from commit 04211c3532)
The result was that at 32bpp, pixmaps of width 8192 or greater couldn't be
created, due to treating a pitch value as a width.
(cherry picked from commit bc2d516f16)
This patch (and not setting HARDWARE_CURSOR_BIT_ORDER_MSBFIRST on big endian
platforms) fixes it for me with the radeon driver and doesn't break intel.
Correct patch this time :)
(cherry picked from commit da973e962d)
