Instead of everybody directly accessing the (internal) screenInfo struct,
let those consumers only interested in first screen use a little helper.
Also caching the value if it's needed several times.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several of the SProcRender*() functions aren't actually needed, because
they're doing exactly the same as their ProcRender*() counterparts.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since Xinerama stuff doesn't tweak the call tables anymore, there's no need
to use them anymore - instead call the corresponding handlers directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In order to consolidate protocol parsing (eg. byte-swapping) and dispatch
(eg. getting rid of the ugly call tables), we first need to untwist the
horribly complicated Xinerama machinery: it's using call tables which are
dynamically tweaked (when Xinerama is switched on/off), and even more call
tables for the byte-swap functions.
Simplifying the code flow by adding trivial demux handlers, which are calling
either into classic/single-mode or xinerama handlers, depending on whether
Xinerama is active.
Follow-up commits can now move the byte-wapping into here and drop the call tables.
After that, the currently duplicated parsing can also be moved in here, and
finally split off the classic/single-mode functions into protocol handling vs.
business logic, so we can finally stop faking requests from Xinerama side into
the classic handlers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Move the walking loops on Xinerama screens into lambda-esque macros:
the callers look quite like we've been using lambda functions and
closures, but actually are just fancy macro trickery.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
When a xinerama-enabled handler is calling into the plain one, there's
no need to go through extra call table - we can call them directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use x_rpcbuf_t for reply payload assembly and X_SEND_REPLY_WITH_RPCBUF()
for sending it all out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
instead of reusing one variable for different things, put it into local
scopes, so things can't ever get mixed up.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
When iterating screen lists, consistently use the same variable name
`walkScreenIdx` for holding current screen index everywhere.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use x_rpcbuf_t for reply payload assembly and X_SEND_REPLY_WITH_RPCBUF()
for sending it all out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use x_rpcbuf_t for reply payload assembly and X_SEND_REPLY_WITH_RPCBUF()
for sending it all out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
When iterating screen lists, consistently use the same variable name
`walkScreen` for holding current screen pointer everywhere.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since most of the extension init logic (and on/off switches for them)
is driven from miext, this seems the appropriate place for the header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use their actual path instead of relying this to be in compiler's
include path list.
* no need to do it only conditionally, no #ifdef needed
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
PANORAMIX was the original working title of the extension, before it became
official standard. Just nobody cared about fixing the symbols to the official
naming.
For backwards compatibility with drivers, the old PANORAMIX symbol will
still be set.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1258>
The symbol controls whether to include dix-config.h, and it's always set,
thus we don't need it (and dozens of ifdef's) anymore.
This commit only removes them from our own source files, where we can
guarantee that dix-config.h is present - leaving the (potentially exported)
headers untouched.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Windows' native headers using some our RT_* define's names for other things.
Since the naming isn't very nice anyways, introducing some new ones
(X11_RESTYPE_NONE, X11_RESTYPE_FONT, X11_RESTYPE_CURSOR) and define the old
ones as an alias to them, in case some out-of-tree code still uses them.
With thins change, we don't need to be so extremely careful about include
ordering and have explicit #undef's in order to prevent name clashes on
Win32 targets.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1355>
Previously, AllocateGlyph would return a new glyph with refcount=0 and a
re-used glyph would end up not changing the refcount at all. The
resulting glyph_new array would thus have multiple entries pointing to
the same non-refcounted glyphs.
AddGlyph may free a glyph, resulting in a UAF when the same glyph
pointer is then later used.
Fix this by returning a refcount of 1 for a new glyph and always
incrementing the refcount for a re-used glyph, followed by dropping that
refcount back down again when we're done with it.
CVE-2024-31083, ZDI-CAN-22880
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1463>
ZDI-CAN-14192, CVE-2021-4008
This vulnerability was discovered and the fix was suggested by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
This ensures that any prep work for the drawable we're about to read
from is already done before we call down to GetImage. This should be no
functional change as most of the callers with a non-trivial
SourceValidate are already wrapping GetImage and doing the equivalent
thing, but we'll be simplifying that shortly.
More importantly this ensures that if any of that prep work would
generate events - like automatic compositing flushing rendering to a
parent pixmap which then triggers damage - then it happens entirely
before we start writing the GetImage reply header.
Note that we do not do the same for GetSpans, but that's okay. The only
way to get to GetSpans is through miCopyArea or miCopyPlane - where the
callers must already call SourceValidate - or miGetImage - which this
commit now protects with SourceValidate.
Fixes: xorg/xserver#902
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
ProcRenderCreateRadialGradient and ProcRenderCreateConicalGradient must
be protected against an integer overflow during length check. This is
already included in ProcRenderCreateLinearGradient since the fix for
CVE-2008-2362.
This can only be successfully exploited on a 32 bit system for an
out of boundary read later on. Validated by using ASAN.
Reviewed-by: Adam Jackson <ajax@redhat.com>
This touches everything that ends up in the Xorg binary; the big missing
part is GLX since that's all generated code. Cuts about 14k from the
binary on amd64.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Since ProcRenderScale throws BadImplementation anyway it's pointless to
waste time carefully swapping the request.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Just throw BadPicture instead of crashing. It's not currently a
meaningful thing to do anyway, RenderSetPictureRectangles would error if
you tried (which this patch changes to BadPicture as well for
consistency). The problem with trying to do it is if the clip is
specified as a pixmap then we try to convert it to a region, and
->BitmapToRegion requires a ScreenPtr, and source-only pictures don't
have one.
I can imagine a use for client clip on source-only pictures, so if we
really wanted to allow this, probably the way forward is to always store
the clip as a region internally, and when setting the clip _from_ a
pixmap, look up BitmapToRegion relative to the pixmap not the picture.
But since clearly nobody can be relying on it working...
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
