Since we already had to rename some of them, in order to fix name clashes
on win32, it's now time to rename all the remaining ones.
The old ones are still present as define's to the new ones, just for
backwards compatibility.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1355>
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>
This function isn't used by any drivers, so no need to export it.
Also has just one consumer, so move it there and make it static.
(and also move ISOLatin1ToLower() along with it)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1374>
ProcRenderAddGlyphs() adds the glyph to the glyphset using AddGlyph() and
then frees it using FreeGlyph() to decrease the reference count, after
AddGlyph() has increased it.
AddGlyph() however may chose to reuse an existing glyph if it's already
in the glyphSet, and free the glyph that was given, in which case the
caller function, ProcRenderAddGlyphs() will call FreeGlyph() on an
already freed glyph, as reported by ASan:
READ of size 4 thread T0
#0 in FreeGlyph xserver/render/glyph.c:252
#1 in ProcRenderAddGlyphs xserver/render/render.c:1174
#2 in Dispatch xserver/dix/dispatch.c:546
#3 in dix_main xserver/dix/main.c:271
#4 in main xserver/dix/stubmain.c:34
#5 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#6 in __libc_start_main_impl ../csu/libc-start.c:360
#7 (/usr/bin/Xwayland+0x44fe4)
Address is located 0 bytes inside of 64-byte region
freed by thread T0 here:
#0 in __interceptor_free libsanitizer/asan/asan_malloc_linux.cpp:52
#1 in _dixFreeObjectWithPrivates xserver/dix/privates.c:538
#2 in AddGlyph xserver/render/glyph.c:295
#3 in ProcRenderAddGlyphs xserver/render/render.c:1173
#4 in Dispatch xserver/dix/dispatch.c:546
#5 in dix_main xserver/dix/main.c:271
#6 in main xserver/dix/stubmain.c:34
#7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
previously allocated by thread T0 here:
#0 in __interceptor_malloc libsanitizer/asan/asan_malloc_linux.cpp:69
#1 in AllocateGlyph xserver/render/glyph.c:355
#2 in ProcRenderAddGlyphs xserver/render/render.c:1085
#3 in Dispatch xserver/dix/dispatch.c:546
#4 in dix_main xserver/dix/main.c:271
#5 in main xserver/dix/stubmain.c:34
#6 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
SUMMARY: AddressSanitizer: heap-use-after-free xserver/render/glyph.c:252 in FreeGlyph
To avoid that, make sure not to free the given glyph in AddGlyph().
v2: Simplify the test using the boolean returned from AddGlyph() (Michel)
v3: Simplify even more by not freeing the glyph in AddGlyph() (Peter)
Fixes: bdca6c3d1 - render: fix refcounting of glyphs during ProcRenderAddGlyphs
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1659
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1476>
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>
This header is never exported and belongs to OS layer, thus no need to have it
in include/ directory, where all the public ones are - better off under os/.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1350>
Public module API headers don't need / shouldn't to contain anything that
isn't part of the API (non-exported functions, etc).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1287>
Public module API headers don't need / shouldn't to contain anything that
isn't part of the API (non-exported functions, etc).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1287>
Over 1.5 decades ago, pixmap handling was moved to using pixman library,
but there's still a bit fallout from that left. Cleaning it up now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1287>
In GLES2, we cannot do GL_RED or GL_RG without GL_EXT_texture_rg.
So, add check for GL_EXT_texture_rg to make it working. Also add
a yuv2 pixman format into render.h to make Xv yuv rendering works.
Signed-off-by: Yuriy Vasilev <uuvasiliev@yandex.ru>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
The xserver fails to compile with the latest gcc 12:
render/picture.c: In function ‘CreateSolidPicture’:
render/picture.c:874:26: error: array subscript ‘union _SourcePict[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
874 | pPicture->pSourcePict->type = SourcePictTypeSolidFill;
| ^~
render/picture.c:868:45: note: object of size 16 allocated by ‘malloc’
868 | pPicture->pSourcePict = (SourcePictPtr) malloc(sizeof(PictSolidFill));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
render/picture.c: In function ‘CreateLinearGradientPicture’:
render/picture.c:906:26: error: array subscript ‘union _SourcePict[0]’ is partly outside array bounds of ‘unsigned char[32]’ [-Werror=array-bounds]
906 | pPicture->pSourcePict->linear.type = SourcePictTypeLinear;
| ^~
render/picture.c:899:45: note: object of size 32 allocated by ‘malloc’
899 | pPicture->pSourcePict = (SourcePictPtr) malloc(sizeof(PictLinearGradient));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
render/picture.c: In function ‘CreateConicalGradientPicture’:
render/picture.c:989:26: error: array subscript ‘union _SourcePict[0]’ is partly outside array bounds of ‘unsigned char[32]’ [-Werror=array-bounds]
989 | pPicture->pSourcePict->conical.type = SourcePictTypeConical;
| ^~
render/picture.c:982:45: note: object of size 32 allocated by ‘malloc’
982 | pPicture->pSourcePict = (SourcePictPtr) malloc(sizeof(PictConicalGradient));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
ninja: build stopped: subcommand failed.
This is because gcc 12 has become stricter and raises a warning now.
Fix the warning/error by allocating enough memory to store the union
struct.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1256
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>
On FreeBSD 13.0-CURRENT for PowerPC64 big-endian (BE), X was
crashing in some cases. For instance, when twm was started
and the background was clicked to open its menu, X crashed
with a segmentation fault, trying to dereference a null pointer
at CreatePicture().
There were 2 issues with xorg-server handling of RGB masks that
caused the pointer above to be null and thus the crash:
- wrong use of ffs() to get the RGB offsets from the masks
- overflow when shifting a 16-bit integer
This change fixes both issues. They happen when the system is BE
but has a video adapter using a little-endian (LE) ARGB32
framebuffer. In order to display the correct colors, this setup
requires a BE RGBA32 color format to be used by X, by setting
the RGB masks appropriately, that didn't work properly because of
the issues above.
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>
Slightly simplifies the callers since they don't need to check for
non-NULL anymore.
I do extremely hate the workarounds here to suppress misprite taking the
cursor down though. Surely there's a better way.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Delightfully this is undefined even though CARD16 is an "unsigned" type,
because it's an unsigned short, which C promotes to signed int because
everything is stupid.
The Render protocol requires this format, but it is wrong to do so. We
are not aware of any hardware with a real 4bpp implementation of this
format. Some GL hardware may have GL_LUMINANCE4_ALPHA4_EXT, and may also
be able to wire L to 1, but that would win you none of memory, quality,
or (likely) performance over A8. Any attempt to use this format is
therefore likely a (painful) software fallback.
Pleasantly (and given the above, unsurprisingly) it seems to be unused
in the wild. None of the major toolkits will try to use it, and
rendercheck does not in fact validate that all of the "standard" picture
formats exist.
Drop the explicit A4 setup from picture format initialization. Note that
the DDXes are not changed and still expose a depth-4 pixmap format, but
we only add picture formats for True/DirectColor-credible depths (i.e.
depth >= 15).
Implements: xorg/proto/xorgproto!1
Signed-off-by: Adam Jackson <ajax@redhat.com>
Install missing headers to the SDK directory to allow external modules
to properly build against the SDK. After this commit, the list of files
installed in the SDK include directory is the same as the list of files
installed by the autotools-based build.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This plumbs the full width color for solid pictures through to fb, exa,
and glamor. External drivers and acceleration code may wish to make a
similar change for sufficiently new servers.
v2: Don't break ABI (Michel Dänzer)
v2.1: Use the (correct) full color in fb too (Michel Dänzer)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Make a solid-fill picture for this instead of a 1x1 pixmap. In principle
the backend can accelerate this directly, and we also get to preserve
all the bits of the fill color.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Formerly spriteInfo->anim.pCursor would point to the animated cursor (or
NULL if not animated). That value would also be available in
spriteInfo->sprite->current, so instead lets use anim.pCursor to point
to the current animation element.
Signed-off-by: Adam Jackson <ajax@redhat.com>
We weren't cancelling the old timer when changing cursors, making things
go all crashy. Logically we could always cancel the timer first, but
then we'd have to call TimerSet to re-arm ourselves, and GetTimeInMillis
is potentially expensive.
Reported-by: https://devtalk.nvidia.com/default/topic/1028172/linux/titan-v-ubuntu-16-04lts-and-387-34-driver-crashes-badly/post/5230967/#5230967
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Tested-by: Aaron Plattner <aplattner@nvidia.com>
This is very slightly more efficient since the callback now doesn't need
to walk every input device, instead we know exactly which device's
cursor is being updated. AnimCurTimerNotify() gets outdented nicely as a
result. A more important side effect is that we can stop using the
TimerAbsolute mode and just pass in the relative delay.
In AnimCurSetCursorPosition, we no longer need to rearm the timer with
the new screen; it is enough to update the device's state. In
AnimCurDisplayCursor we need to notice when we're switching from
animated cursor to regular and cancel the existing timer.
Reviewed-by: Robert Morell <rmorell@nvidia.com>
Tested-by: Robert Morell <rmorell@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
If the return value is non-zero here, DoTimer() will automatically rearm
the timer for the new (relative) delay. 'soonest' is in absolute time,
so subtract off 'now' and return that.
Reviewed-by: Robert Morell <rmorell@nvidia.com>
Tested-by: Robert Morell <rmorell@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Roundhouse kick replacing the various (sizeof(foo)/sizeof(foo[0])) with
the ARRAY_SIZE macro from dix.h when possible. A semantic patch for
coccinelle has been used first. Additionally, a few macros have been
inlined as they had only one or two users.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest,
and Xdmx so far. The outline of Xquartz/Xwin support is in tree, but
hasn't been built yet. The unit tests are also not done.
The intent is to build this as a complete replacement for the
autotools system, then eventually replace autotools. meson is faster
to generate the build, faster to run the bulid, shorter to write the
build files in, and less error-prone than autotools.
v2: Fix indentation nits, move version declaration to project(), use
existing meson_options for version-config.h's vendor name/web.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Fixes freedesktop.org bug https://bugs.freedesktop.org/show_bug.cgi?id=67484
If t->bottom is close to MIN_INT, removing top can wraparound, so do the check properly.
A similar fix should also be applied to pixman.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Probably pointless, if this fails you're not likely to get far...
Reviewed-by: Rémi Cardona <remi@gentoo.org>
Signed-off-by: Julien Cristau <jcristau@debian.org>
This replaces the block/wakeup handlers with an OsTimer. This also
avoids problems with performing rendering during the wakeup handler.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
All the callers were already checking for failure, except that
createSourcePicture() itself was failing to check whether it
successfully allocated the Picture.
[ajax: Rebase, fix line wrap of preceding line]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
==11097== 2,048 (+1,640) bytes in 32 (+26) blocks are definitely lost in loss record 1,570 of 1,719
==11097== at 0x4C2A2DB: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11097== by 0x225EF3: SetPicturePictFilter (filter.c:339)
==11097== by 0x22DF4F: ProcRenderSetPictureFilter (render.c:1773)
==11097== by 0x15D25D: Dispatch (dispatch.c:432)
==11097== by 0x14C7B9: main (main.c:298)
[ajax: Fixed whitespace]
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
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>
Enrico Weigelt, metux IT consult
Olivier Fourdan
Peter Hutterer
Yuriy
Povilas Kanapickas
luporl
Jan Beich
Adam Jackson
Thierry Reding
Daniel Martin
Nathan Kidd
Eric Anholt
Tobias Stoeckmann
Maarten Lankhorst
Julien Cristau
Keith Packard
Chris Wilson
Andrea Canciani
Alan Coopersmith