Eventually, drmmode_display will be able to use GBM for handling
buffers, and won't need dumb_bo. Keeping the display related logic
and buffer object abstraction in separate files seems a bit tidier.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
This will need to change when we add GBM support; by pulling it into a
helper function, we should only have to edit one place.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Both branches called ModifyPixmapHeader with essentially the same
parameters. By using new_pixels in the shadowfb case, we can make
them completely the same, and move them out a level, for simplicity.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
The _ext variant takes an additional pointer argument, which it now
ignores, thanks to Keith's recent patches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
They are part of the ABI.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Xephyr's pseudocolor emulation added in:
commit 81a3b6fe27
Author: Matthew Allum <breakfast@10.am>
Date: Mon Nov 8 22:39:47 2004 +0000
Add support to Xephyr for lower depths than hosts
only tracks one global colormap for the whole (Xephyr) display. Move
this to per-screen state so each screen's colormap can be correct.
[ajax: rebased to 1.17, cleaned up commit message]
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Michele Baldessari <michele@redhat.com>
Some people like to call this on bare Window XIDs and expect reasonable
results. I sure wish they wouldn't, but since they do, if we're given
a window without any glx decoration just fill in as much as we can. This
means you won't actually get an answer for GLX_FBCONFIG_ID and friends,
but there's not much to be done about that, and it matches what NVIDIA's
driver seems to do.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54080
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This adds a dummy implementation for the loseCurrent function in
__GLXContext for direct contexts which just returns GL_TRUE. Without
this then the X server can crash if receives a MakeCurrent message for
a direct context because it will attempt to call loseCurrent when
cleaning up the client in the callback for ClientStateGone.
[ajax: added assumed s-o-b line]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86531
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Neil Roberts <neil@linux.intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
GetHosts saves the pointer to allocated memory in *data, and then
wants to bounds-check writes to that region, but was mistakenly using
a bare 'data' instead of '*data'. Also, data is declared as void **,
so we need a cast to turn it into a byte pointer so we can actually do
pointer comparisons.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The 'n' parameter must be surrounded by parens in both places to
prevent precedence from mis-computing things.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
We're using compiler compatibility settings which generate warnings
when a variable is declared after the first statement.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
When the local types used to walk the DBE request were changed, this
changed the type of the parameter passed to the DDX SwapBuffers API,
but there wasn't a matching change in the API definition.
At this point, with the API frozen, I just stuck a new variable in
with the correct type. Because we've already bounds-checked nStuff to
be smaller than UINT32_MAX / sizeof(DbeSwapInfoRec), we know it will
fit in a signed int without overflow.
Signed-off-by: Keith Packard <keithp@keithp.com
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
When reallocating the framebuffer on screen resize, the old EGL image
was getting leaked. Check for an existing EGL image and free it in
this case.
Signed-off-by: Keith Packard <keithp@keithp.com>
Revewied-by: Zhigang Gong <zhigang.gong@linux.intel.com>
There's no reason to store this in the egl screen private as the
screen pixmap will always hold a reference to it anyways.
Signed-off-by: Keith Packard <keithp@keithp.com>
Revewied-by: Zhigang Gong <zhigang.gong@linux.intel.com>
There were three paths that called eglDestroyImageKHR:
* The front buffer
* The intel driver's flip buffer
* pixmaps under DRI3
This patch unifies the second two by having glamor_destroy_pixmap
always destroy any associaged EGL image. This allows us to stop
storing the back_pixmap pointer in glamor as that was only used to
make sure that buffer was freed at server reset time.
v2: check for valid pixmap_priv before using it in
glamor_egl_destroy_pixmap_image
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
On a system where sizeof(unsigned) != sizeof(intptr_t), the unary
bitwise not operation will result in a mask that clears all high bits
from temp_buf in the expression:
temp_buf = (temp_buf + mask) & ~mask;
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
v2: Handle more multiplies in indirect_reqsize.c (Julien Cristau)
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
v2:
Fix single versus vendor-private length checking for ARB_imaging subset
extensions. (Julien Cristau)
v3:
Fix single versus vendor-private length checking for ARB_imaging subset
extensions. (Julien Cristau)
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This is a half-measure until we start passing request length into the
varsize function, but it's better than the nothing we had before.
v2: Verify that there's at least a large render header's worth of
dataBytes (Julien Cristau)
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
v2:
Fix constants in __glXMap2fReqSize (Michal Srb)
Validate w/h/d for proxy targets too (Keith Packard)
v3:
Fix Map[12]Size to correctly reject order == 0 (Julien Cristau)
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
v2:
Remove can't-happen comparison for cmdlen < 0 (Michal Srb)
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
These are paranoid about integer overflow, and will return -1 if their
operation would overflow a (signed) integer or if either argument is
negative.
Note that RenderLarge requests are sized with a uint32_t so in principle
this could be sketchy there, but dix limits bigreqs to 128M so you
shouldn't ever notice, and honestly if you're sending more than 2G of
rendering commands you're already doing something very wrong.
v2: Use INT_MAX for consistency with the rest of the server (jcristau)
v3: Reject negative arguments (anholt)
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Without this we'd reject the request with BadLength. Note that some old
versions of Mesa had a bug in the same place, and would _send_ zero
bytes of image data; these will now be rejected, correctly.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
If the computed reply size is negative, something went wrong, treat it
as an error.
v2: Be more careful about size_t being unsigned (Matthieu Herrb)
v3: SIZE_MAX not SIZE_T_MAX (Alan Coopersmith)
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Before this we'd just clamp the image size to 0, which was just
hideously stupid; if the parameters were such that they'd overflow an
integer, you'd allocate a small buffer, then pass huge values into (say)
ReadPixels, and now you're scribbling over arbitrary server memory.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
If the size computation routine returns -1 we should just reject the
request outright. Clamping it to zero could give an attacker the
opportunity to also mangle cmdlen in such a way that the subsequent
length check passes, and the request would get executed, thus passing
data we wanted to reject to the renderer.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Otherwise we may be reading outside of the client request.
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Multiple functions in the Xinput extension handling of requests from
clients failed to check that the length of the request sent by the
client was large enough to perform all the required operations and
thus could read or write to memory outside the bounds of the request
buffer.
This commit includes the creation of a new REQUEST_AT_LEAST_EXTRA_SIZE
macro in include/dix.h for the common case of needing to ensure a
request is large enough to include both the request itself and a
minimum amount of extra data following the request header.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
ProcDbeSwapBuffers() has a 32bit (n) length value that it uses to read
from a buffer. The length is never validated, which can lead to out of
bound reads, and possibly returning the data read from out of bounds to
the misbehaving client via an X Error packet.
SProcDbeSwapBuffers() swaps data (for correct endianness) before
handing it off to the real proc. While doing the swapping, the
length field is not validated, which can cause memory corruption.
v2: reorder checks to avoid compilers optimizing out checks for overflow
that happen after we'd already have done the overflowing multiplications.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
ProcDRI2GetBuffers() tries to validate a length field (count).
There is an integer overflow in the validation. This can cause
out of bound reads and memory corruption later on.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Force use of 64-bit integers when evaluating data provided by clients
in 32-bit fields which can overflow when added or multiplied during
checks.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
RegionSizeof contains several integer overflows if a large length
value is passed in. Once we fix it to return 0 on overflow, we
also have to fix the callers to handle this error condition
v2: Fixed limit calculation in RegionSizeof as pointed out by jcristau.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
GetHosts() iterates over all the hosts it has in memory, and copies
them to a buffer. The buffer length is calculated by iterating over
all the hosts and adding up all of their combined length. There is a
potential integer overflow, if there are lots and lots of hosts (with
a combined length of > ~4 gig). This should be possible by repeatedly
calling ProcChangeHosts() on 64bit machines with enough memory.
This patch caps the list at 1mb, because multi-megabyte hostname
lists for X access control are insane.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
ProcPutImage() calculates a length field from a width, left pad and depth
specified by the client (if the specified format is XYPixmap).
The calculations for the total amount of memory the server needs for the
pixmap can overflow a 32-bit number, causing out-of-bounds memory writes
on 32-bit systems (since the length is stored in a long int variable).
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
authdes_ezdecode() calls malloc() using a length provided by the
connection handshake sent by a newly connected client in order
to authenticate to the server, so should be treated as untrusted.
It didn't check if malloc() failed before writing to the newly
allocated buffer, so could lead to a server crash if the server
fails to allocate memory (up to UINT16_MAX bytes, since the len
field is a CARD16 in the X protocol).
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>