https://github.com/X11Libre/xserver/issues/2890
musl doesn't indirectly include errno.h as much as other libc's do.
In general it's a good idea to always explicitly include what's needed,
instead of relying on indirect includes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's only ~100 loc, so even it noone uses this, it's not that much code.
The author of this is probably Keith Packard, but I couldn't find
a commit adding this driver, so I didn't put him as the commit author.
Reverts: af1f1a05e1 ,
after porting it to meson, C99 struct init, and some C99 fixes
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
CheckKeyActions() validates the per-key action count bytes individually
but does not verify that the computed total action data region falls
within the request buffer before advancing the wire pointer past it.
After the loop, the function calculates the final wire position as
wire + nActs * sizeof(XkbAnyAction), where nActs is the sum of per-key
action counts read from the request. The upstream length validation in
_XkbSetMapCheckLength() uses req->totalActs from the request header,
not the computed nActs. If a crafted request provides a totalActs value
that passes the length check but per-key action counts that sum to a
different nActs, the wire pointer could advance past the actual request
buffer.
The subsequent SetKeyActions() function uses memcpy to read from this
potentially out-of-bounds region, which could leak heap data or cause
a crash.
Assisted-by: Claude:claude-claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2208>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The for loop here always iterates size times but the client controls the
starting offset. When the starting pixel is non-zero (e.g., pixel=10 in
a size=256 colormap), the loop reads from pentFirst[10] through
pentFirst[265], reading 10 entries past the end of the array.
Fix this by wrapping around once we reach size, same as FindColor()
already does.
Assisted-by: Claude:claude-claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2215>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to spin for a zero-length change. The loop is already bounded to
255 iterations so this just keeps the room slightly cooler.
This is a slight behavior change in that subsequent hierarchy changes
will no longer be accepted (but already-applied changes remain). But a
client sending zero length hierarchy changes is buggy anyway, so meh.
Assisted-by: Claude:claude-claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2200>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In siHostnameCheckAddr(), the digit validation range was 0x30-0x3A, but
0x3A is the colon character (':'). The ASCII range for digits 0-9 is
0x30-0x39.
Colons in hostnames violate RFC 2396 section 3.2.2 and we're not parsing
the host:port notation here.
Assisted-by: Claude:claude-claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2200>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now special key combinations work in all kdrive X servers,
and the special key combinations are documented in the various man pages.
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
Since this function is called from signal handlers (e.g. OsSigHandler
processing SIGSEGV/SIGBUS), a NULL %s argument triggers a recursive fault.
Assisted-by: Claude:claude-claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2200>
----------------------------------------------------------------------------
Modified to fit Xlibre changes.
See: https://github.com/X11Libre/xserver/pull/2794
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
CheckKeyTypes computes nMaps = firstType + nTypes from client-controlled
request fields when XkbSetMapResizeTypes is set. This value is used to
index mapWidths[], a stack-allocated CARD8 array of XkbMaxLegalKeyCode + 1
(256) elements. No upper bound is enforced on nMaps.
An attacker can first send SetMap(firstType=0, nTypes=255, ResizeTypes) to
set the server's num_types to 255, then send SetMap(firstType=255,
nTypes=10, ResizeTypes). The firstType > num_types check passes because
255 > 255 is false (the check uses > rather than >=). nMaps is then
computed as 265, and the loop writes mapWidths[255..264], overflowing 9
bytes past the stack buffer into adjacent stack variables (symsPerKey[]).
Fix by rejecting requests where firstType + nTypes would exceed the
mapWidths buffer size (XkbMaxLegalKeyCode + 1).
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-30161
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
_Concat() stored the realloc() result directly in its input pointer, so
an allocation failure could drop the only reference to the original
buffer when callers assigned the return value back to their destination
pointer.
Keep the old pointer until realloc() succeeds, avoiding the leak
reported by static analysis.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2221>
ospoll_create() initializes backend-specific state immediately after
allocating the ospoll structure. Check the allocation result for each
backend before dereferencing it and return NULL on failure.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2217>
This works as intended — the (fake) front buffer needs to be added
only if the client didn't request it in the first place — even if the
client requests the same attachment multiple times. This ensures we
never try to access more than (count + 1) entries of the buffers array.
Fixes: ff6c7764c2 ("DRI2: Implement protocol for DRI2GetBuffersWithFormat")
Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
This is the equivalent check to miSyncTriggerFence() from
commit f19ab94ba9 ("miext/sync: Fix use-after-free in miSyncTriggerFence()")
When a trigger fires via SyncAwaitTriggerFired, the resulting
FreeResource/FreeAwait call invokes SyncDeleteTriggerFromSyncObject for
every trigger in the same Await group. This unlinks and frees the
corresponding trigger list nodes - potentially including the node pnext
points to.
Fix by restarting iteration from the list head after a trigger fires, since
TriggerFired may have arbitrarily mutated the list. Triggers that have fired
are removed from the list by FreeAwait, so restarting cannot cause infinite
loops.
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-30164
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
CheckKeyTypes validates incoming key type definitions from XkbSetMap
requests but does not enforce an upper bound on numLevels. A client can set
numLevels up to 255 on a non-canonical key type, which is stored in the
server's type table.
When ChangeKeyboardMapping later triggers XkbUpdateKeyTypesFromCore, the
function XkbKeyTypesForCoreSymbols computes groupsWidth from num_levels and
uses the XKB_OFFSET(g, l) = (g * groupsWidth) + l macro to index into
tsyms[], a stack-allocated buffer of XkbMaxSymsPerKey (252) entries. With
num_levels=255, groupsWidth=255, and indices reach up to 3*255+254 = 1019,
overflowing the 252-element stack buffer by 767 KeySym-sized entries.
Fix by rejecting numLevels values greater than XkbMaxShiftLevel (63) in
CheckKeyTypes, alongside the existing lower-bound check for numLevels < 1.
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-30160
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request length validation in __glXDisp_ChangeDrawableAttributes and
__glXDispSwap_ChangeDrawableAttributes uses the wrong comparison direction.
The check tests whether the computed request size is LESS THAN
client->req_len, but should test whether it is GREATER THAN. With the
reversed operator, an undersized request (where numAttribs claims more
attribute pairs than the request actually contains) passes validation.
DoChangeDrawableAttributes then iterates numAttribs attribute pairs starting
from the end of the request header, reading past the actual request data
into adjacent memory. This is an out-of-bounds read that can also cause
an out-of-bounds write when a GLX_EVENT_MASK attribute key is found in the
overread data and its corresponding value is written to pGlxDraw->eventMask.
This patch effectively reverts commit 402b329c3a ("glx: Work around
wrong request lengths sent by mesa"). This was fixed in mesa commit
4324d6fdfbba1 in 2011 (mesa 7.11).
Fixes: 402b329c3a ("glx: Work around wrong request lengths sent by mesa")
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-30165
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
CreateSaverWindow stores pPriv (the ScreenSaverScreenPrivatePtr) in a local
variable via the SetupScreen macro at function entry. When an existing saver
window is being replaced, the function sets pPriv->hasWindow = FALSE and
calls CheckScreenPrivate(). If at this point pPriv->attr is NULL (cleared
by a prior UnsetAttributes call), pPriv->events is NULL, and
pPriv->installedMap is None, then CheckScreenPrivate determines the screen
private is unused, frees it, and sets the screen private pointer to NULL.
The function then continues to dereference the now-freed pPriv on the very
next line (pPriv->attr), resulting in a use-after-free. On glibc 2.34+,
the tcache key at offset 8 within the freed block makes pPriv->attr appear
non-NULL, causing the function to continue operating on garbage data and
eventually crash.
The attack sequence is:
1. SetAttributes (creates pPriv with pPriv->attr set)
2. ForceScreenSaver(Active) (creates saver window, pPriv->hasWindow=TRUE)
3. UnsetAttributes (sets pPriv->attr = NULL)
4. ForceScreenSaver(Active) (re-enters CreateSaverWindow → UAF)
Fix by re-fetching pPriv from the screen private after CheckScreenPrivate
returns, so the subsequent NULL check correctly detects the freed state.
ScreenSaverFreeAttr has the same pattern, force pPriv to NULL there too
even though it has no real effect.
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-30168
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
XLFDMAXFONTNAMELEN was 256 bytes, but libXfont2 defines MAXFONTNAMELEN
as 1024 and allows font names and alias targets up to that length in
fonts.alias files.
doListFontsAndAliases copies the resolved alias target into a
stack-allocated tmp_pattern[XLFDMAXFONTNAMELEN] and then into
c->current.pattern[XLFDMAXFONTNAMELEN] (defined in LFWIstateRec).
doListFontsWithInfo has the same pattern, copying the resolved name into
c->current.pattern[]. With the old 256-byte limit, a fonts.alias entry
with a target name between 257 and 1023 bytes would overflow both
buffers.
An attacker can exploit this by:
1. Creating a font directory with a fonts.alias containing an alias
whose target name exceeds 256 bytes
2. Using SetFontPath to add the malicious directory
3. Calling ListFonts with the alias name to trigger alias resolution
4. The oversized resolved name overflows the 256-byte stack buffer
Increase XLFDMAXFONTNAMELEN from 256 to 1024 to match libXfont2's
MAXFONTNAMELEN, ensuring the server can handle any name the font library
produces.
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-30136
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Both FreeCounter() and miSyncDestroyFence() iterate over the trigger list
and invoke the CounterDestroyed callback on each trigger.
The CounterDestroyed callback (e.g. SyncAwaitTriggerFired) may call
FreeResource/FreeAwait, which frees the SyncAwaitUnion containing all
SyncAwait structs in the same Await group.
When multiple conditions in a single Await reference the same sync
object (counter or fence), the first callback frees all SyncAwait
structs while subsequent trigger list nodes still reference them. On the
next iteration, reading ptl->next or ptl->pTrigger dereferences freed
memory, leading to a use-after-free.
We need separate fixes for separate issues here to fix this in one go
- use our null-terminated list macro to make sure our next pointer stays
valid (the code accessed ptl->next after freeing it)
- update the list head before deleting the trigger, eventually this ends
up being NULL anyway but meanwhile the list head is a valid list
during CounterDestroyed
- check if we actually do have a trigger before dereferencing the
callback
- Set all triggers to NULL if they are shared so we don't dereference
potentially freed memory
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-30159 (miSyncDestroyFence), ZDI-CAN-30163 (FreeCounter)
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
With this change, we create EGLImages directly from the GL
texture of the pixmap to be exported, and set the pixmap's image
to the newly created EGLImage.
Before this, we were creating a gbm bo with the same dimensions
as the pixmap. We were then creating a new pixmap with the dimensions
of the old pixmap. We were then exporting the gbm bo as dmabufs, and
importing the dmabufs into an EGLImage. We were then creating a GL
texture from this EGLImage, and we were setting the newly created pixmap's
texture and EGLImage to the newly created ones.
Then we were swapping the texture and image of the newly created pixmap into
the old pixmap, and destroying the newly created pixmap.
DRI3 pixmap exports are a pretty rare operation.
Most of the time, we do pixmap imports.
As such, here is some code for testing this change.
I cannot attest to the quality of the test code, as I have
copied the code from somewhere else and did not write it myself:
```
// compile with:
// gcc dri3_export_demo.c -o dri3_export_demo \
// -lxcb -lxcb-dri3 -lxcb-present -lxcb-xfixes
int main() {
xcb_connection_t *conn = xcb_connect(NULL, NULL);
if (xcb_connection_has_error(conn)) {
fprintf(stderr, "Failed to connect to X\n");
return 1;
}
const xcb_setup_t *setup = xcb_get_setup(conn);
xcb_screen_iterator_t iter = xcb_setup_roots_iterator(setup);
xcb_screen_t *screen = iter.data;
// Create a pixmap
xcb_pixmap_t pixmap = xcb_generate_id(conn);
uint16_t width = 256, height = 256;
xcb_create_pixmap(conn,
screen->root_depth,
pixmap,
screen->root,
width,
height);
xcb_flush(conn);
printf("Created pixmap %u\n", pixmap);
xcb_generic_error_t *error = NULL;
// --- Single FD export (fd_from_pixmap) ---
xcb_dri3_buffer_from_pixmap_cookie_t cookie1 =
xcb_dri3_buffer_from_pixmap(conn, pixmap);
//xcb_generic_error_t *error = NULL;
xcb_dri3_buffer_from_pixmap_reply_t *reply1 =
xcb_dri3_buffer_from_pixmap_reply(conn, cookie1, &error);
if (!reply1 || error) {
fprintf(stderr, "buffer_from_pixmap failed\n");
free(error);
} else {
int fd = xcb_dri3_buffer_from_pixmap_reply_fds(conn, reply1)[0];
printf("fd_from_pixmap:\n");
printf(" fd = %d\n", fd);
printf(" size = %u\n", reply1->size);
printf(" stride = %u\n", reply1->stride);
printf(" depth = %u\n", reply1->depth);
printf(" bpp = %u\n", reply1->bpp);
close(fd);
free(reply1);
}
// --- Multi-FD export (fds_from_pixmap) ---
xcb_dri3_buffers_from_pixmap_cookie_t cookie2 =
xcb_dri3_buffers_from_pixmap(conn, pixmap);
xcb_dri3_buffers_from_pixmap_reply_t *reply2 =
xcb_dri3_buffers_from_pixmap_reply(conn, cookie2, &error);
if (!reply2 || error) {
fprintf(stderr, "buffers_from_pixmap failed\n");
free(error);
} else {
int nfd = 4;//xcb_dri3_buffers_from_pixmap_reply_fds_length(conn, reply2);
int *fds = xcb_dri3_buffers_from_pixmap_reply_fds(conn, reply2);
printf("fds_from_pixmap:\n");
printf(" num_fds = %d\n", nfd);
printf(" width = %u height = %u\n", reply2->width, reply2->height);
for (int i = 0; i < nfd; i++) {
printf(" fd[%d] = %d\n", i, fds[i]);
close(fds[i]);
}
free(reply2);
}
xcb_free_pixmap(conn, pixmap);
xcb_disconnect(conn);
return 0;
}
```
See: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2057#note_3442757
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
XLibre maintains the Xquartz DDX separately from the Xorg development
repository. Users should know which Xserver they are using when they are
shown the "About" window.
Signed-off-by: Aggelos Tselios <aggelostselios777@gmail.com>
Before this, when we wanted to import pixmaps from dma bufs,
we were importing a gbm bo from dma bufs, exporting the
gbm bo as dmabufs, importing an EGLImageKHR from those
dmabufs, and finally creating a pixmap from the EGLImageKHR.
Now, we just import the image and create a pixmap from it.
See: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2057#note_3442757
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
Similar to `-dumb`, but allows disabling acceleration
for a single screen, as oposed to the whole server
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
