Complete Yocto mirror with license table for TQMa6UL (2038-compliance)

- 264 license table entries with exact download URLs (224/264 resolved)
- Complete sources/ directory with all BitBake recipes
- Build configuration: tqma6ul-multi-mba6ulx, spaetzle (musl)
- Full traceability for Softwarefreigabeantrag
- GCC 13.4.0, Linux 6.6.102, U-Boot 2023.04, musl 1.2.4
- License distribution: GPL-2.0 (24), MIT (23), GPL-2.0+ (18), BSD-3 (16)
This commit is contained in:
Siggi (OpenClaw Agent)
2026-03-01 20:58:18 +00:00
commit 16accb6b24
15086 changed files with 1292356 additions and 0 deletions

View File

@@ -0,0 +1,59 @@
From ba1d14f8eff2a123bd7ff4d48c02e1d5131358e0 Mon Sep 17 00:00:00 2001
From: Matthieu Herrb <matthieu@herrb.eu>
Date: Thu, 10 Oct 2024 10:37:28 +0200
Subject: [PATCH] xkb: Fix buffer overflow in _XkbSetCompatMap()
The _XkbSetCompatMap() function attempts to resize the `sym_interpret`
buffer.
However, It didn't update its size properly. It updated `num_si` only,
without updating `size_si`.
This may lead to local privilege escalation if the server is run as root
or remote code execution (e.g. x11 over ssh).
CVE-2024-9632, ZDI-CAN-24756
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: José Expósito <jexposit@redhat.com>
(cherry picked from commit 85b77657)
Part-of: <!1734>
CVE: CVE-2024-9632
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/ba1d14f8eff2a123bd7ff4d48c02e1d5131358e0]
Signed-off-by: Yogita Urade <yogita.urade@windriver.com>
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
---
xkb/xkb.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xkb/xkb.c b/xkb/xkb.c
index 276dc19..7da00a0 100644
--- a/xkb/xkb.c
+++ b/xkb/xkb.c
@@ -2992,13 +2992,13 @@ _XkbSetCompatMap(ClientPtr client, DeviceIntPtr dev,
XkbSymInterpretPtr sym;
unsigned int skipped = 0;
- if ((unsigned) (req->firstSI + req->nSI) > compat->num_si) {
- compat->num_si = req->firstSI + req->nSI;
+ if ((unsigned) (req->firstSI + req->nSI) > compat->size_si) {
+ compat->num_si = compat->size_si = req->firstSI + req->nSI;
compat->sym_interpret = reallocarray(compat->sym_interpret,
- compat->num_si,
+ compat->size_si,
sizeof(XkbSymInterpretRec));
if (!compat->sym_interpret) {
- compat->num_si = 0;
+ compat->num_si = compat->size_si = 0;
return BadAlloc;
}
}
--
2.40.0

View File

@@ -0,0 +1,54 @@
From 01642f263f12becf803b19be4db95a4a83f94acc Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Wed, 27 Nov 2024 11:27:05 +0100
Subject: [PATCH] Cursor: Refuse to free the root cursor
If a cursor reference count drops to 0, the cursor is freed.
The root cursor however is referenced with a specific global variable,
and when the root cursor is freed, the global variable may still point
to freed memory.
Make sure to prevent the rootCursor from being explicitly freed by a
client.
CVE-2025-26594, ZDI-CAN-25544
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
v2: Explicitly forbid XFreeCursor() on the root cursor (Peter Hutterer
<peter.hutterer@who-t.net>)
v3: Return BadCursor instead of BadValue (Michel Danzer
<michel@daenzer.net>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/01642f26]
CVE: CVE-2025-26594
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
---
dix/dispatch.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/dix/dispatch.c b/dix/dispatch.c
index 4602961..30b95c1 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -3107,6 +3107,10 @@ ProcFreeCursor(ClientPtr client)
rc = dixLookupResourceByType((void **) &pCursor, stuff->id, RT_CURSOR,
client, DixDestroyAccess);
if (rc == Success) {
+ if (pCursor == rootCursor) {
+ client->errorValue = stuff->id;
+ return BadCursor;
+ }
FreeResource(stuff->id, RT_NONE);
return Success;
}
--
2.25.1

View File

@@ -0,0 +1,51 @@
From b0a09ba6020147961acc62d9c73d807b4cccd9f7 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Wed, 4 Dec 2024 15:49:43 +1000
Subject: [PATCH] dix: keep a ref to the rootCursor
CreateCursor returns a cursor with refcount 1 - that refcount is used by
the resource system, any caller needs to call RefCursor to get their own
reference. That happens correctly for normal cursors but for our
rootCursor we keep a variable to the cursor despite not having a ref for
ourselves.
Fix this by reffing/unreffing the rootCursor to ensure our pointer is
valid.
Related to CVE-2025-26594, ZDI-CAN-25544
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/b0a09ba6]
CVE: CVE-2025-26594
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
---
dix/main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/dix/main.c b/dix/main.c
index bfc8add..38e29ce 100644
--- a/dix/main.c
+++ b/dix/main.c
@@ -231,6 +231,8 @@ dix_main(int argc, char *argv[], char *envp[])
FatalError("could not open default cursor font");
}
+ rootCursor = RefCursor(rootCursor);
+
#ifdef PANORAMIX
/*
* Consolidate window and colourmap information for each screen
@@ -271,6 +273,8 @@ dix_main(int argc, char *argv[], char *envp[])
Dispatch();
+ UnrefCursor(rootCursor);
+
UndisplayDevices();
DisableAllDevices();
--
2.25.1

View File

@@ -0,0 +1,65 @@
From 11fcda8753e994e15eb915d28cf487660ec8e722 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Wed, 27 Nov 2024 14:41:45 +0100
Subject: [PATCH] xkb: Fix buffer overflow in XkbVModMaskText()
The code in XkbVModMaskText() allocates a fixed sized buffer on the
stack and copies the virtual mod name.
There's actually two issues in the code that can lead to a buffer
overflow.
First, the bound check mixes pointers and integers using misplaced
parenthesis, defeating the bound check.
But even though, if the check fails, the data is still copied, so the
stack overflow will occur regardless.
Change the logic to skip the copy entirely if the bound check fails.
CVE-2025-26595, ZDI-CAN-25545
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/11fcda87]
CVE: CVE-2025-26595
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
---
xkb/xkbtext.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/xkb/xkbtext.c b/xkb/xkbtext.c
index 0184664207..93262528bb 100644
--- a/xkb/xkbtext.c
+++ b/xkb/xkbtext.c
@@ -173,14 +173,14 @@ XkbVModMaskText(XkbDescPtr xkb,
len = strlen(tmp) + 1 + (str == buf ? 0 : 1);
if (format == XkbCFile)
len += 4;
- if ((str - (buf + len)) <= VMOD_BUFFER_SIZE) {
- if (str != buf) {
- if (format == XkbCFile)
- *str++ = '|';
- else
- *str++ = '+';
- len--;
- }
+ if ((str - buf) + len > VMOD_BUFFER_SIZE)
+ continue; /* Skip */
+ if (str != buf) {
+ if (format == XkbCFile)
+ *str++ = '|';
+ else
+ *str++ = '+';
+ len--;
}
if (format == XkbCFile)
sprintf(str, "%sMask", tmp);
--
GitLab

View File

@@ -0,0 +1,49 @@
From 80d69f01423fc065c950e1ff4e8ddf9f675df773 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Thu, 28 Nov 2024 11:49:34 +0100
Subject: [PATCH] xkb: Fix computation of XkbSizeKeySyms
The computation of the length in XkbSizeKeySyms() differs from what is
actually written in XkbWriteKeySyms(), leading to a heap overflow.
Fix the calculation in XkbSizeKeySyms() to match what kbWriteKeySyms()
does.
CVE-2025-26596, ZDI-CAN-25543
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/80d69f01]
CVE: CVE-2025-26596
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
---
xkb/xkb.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xkb/xkb.c b/xkb/xkb.c
index 85659382da..744dba63d7 100644
--- a/xkb/xkb.c
+++ b/xkb/xkb.c
@@ -1095,10 +1095,10 @@ XkbSizeKeySyms(XkbDescPtr xkb, xkbGetMapReply * rep)
len = rep->nKeySyms * SIZEOF(xkbSymMapWireDesc);
symMap = &xkb->map->key_sym_map[rep->firstKeySym];
for (i = nSyms = 0; i < rep->nKeySyms; i++, symMap++) {
- if (symMap->offset != 0) {
- nSymsThisKey = XkbNumGroups(symMap->group_info) * symMap->width;
- nSyms += nSymsThisKey;
- }
+ nSymsThisKey = XkbNumGroups(symMap->group_info) * symMap->width;
+ if (nSymsThisKey == 0)
+ continue;
+ nSyms += nSymsThisKey;
}
len += nSyms * 4;
rep->totalSyms = nSyms;
--
GitLab

View File

@@ -0,0 +1,46 @@
From 0e4ed94952b255c04fe910f6a1d9c852878dcd64 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Thu, 28 Nov 2024 14:09:04 +0100
Subject: [PATCH] xkb: Fix buffer overflow in XkbChangeTypesOfKey()
If XkbChangeTypesOfKey() is called with nGroups == 0, it will resize the
key syms to 0 but leave the key actions unchanged.
If later, the same function is called with a non-zero value for nGroups,
this will cause a buffer overflow because the key actions are of the wrong
size.
To avoid the issue, make sure to resize both the key syms and key actions
when nGroups is 0.
CVE-2025-26597, ZDI-CAN-25683
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/0e4ed949]
CVE: CVE-2025-26597
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
---
xkb/XKBMisc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xkb/XKBMisc.c b/xkb/XKBMisc.c
index abbfed90eb..fd180fad2c 100644
--- a/xkb/XKBMisc.c
+++ b/xkb/XKBMisc.c
@@ -553,6 +553,7 @@ XkbChangeTypesOfKey(XkbDescPtr xkb,
i = XkbSetNumGroups(i, 0);
xkb->map->key_sym_map[key].group_info = i;
XkbResizeKeySyms(xkb, key, 0);
+ XkbResizeKeyActions(xkb, key, 0);
return Success;
}
--
GitLab

View File

@@ -0,0 +1,120 @@
From bba9df1a9d57234c76c0b93f88dacb143d01bca2 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 16 Dec 2024 11:25:11 +0100
Subject: [PATCH] Xi: Fix barrier device search
The function GetBarrierDevice() would search for the pointer device
based on its device id and return the matching value, or supposedly NULL
if no match was found.
Unfortunately, as written, it would return the last element of the list
if no matching device id was found which can lead to out of bounds
memory access.
Fix the search function to return NULL if not matching device is found,
and adjust the callers to handle the case where the device cannot be
found.
CVE-2025-26598, ZDI-CAN-25740
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/bba9df1a]
CVE: CVE-2025-26598
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
---
Xi/xibarriers.c | 27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/Xi/xibarriers.c b/Xi/xibarriers.c
index 700b2b8c53..6761bcb49a 100644
--- a/Xi/xibarriers.c
+++ b/Xi/xibarriers.c
@@ -132,14 +132,15 @@ static void FreePointerBarrierClient(struct PointerBarrierClient *c)
static struct PointerBarrierDevice *GetBarrierDevice(struct PointerBarrierClient *c, int deviceid)
{
- struct PointerBarrierDevice *pbd = NULL;
+ struct PointerBarrierDevice *p, *pbd = NULL;
- xorg_list_for_each_entry(pbd, &c->per_device, entry) {
- if (pbd->deviceid == deviceid)
+ xorg_list_for_each_entry(p, &c->per_device, entry) {
+ if (p->deviceid == deviceid) {
+ pbd = p;
break;
+ }
}
- BUG_WARN(!pbd);
return pbd;
}
@@ -340,6 +341,9 @@ barrier_find_nearest(BarrierScreenPtr cs, DeviceIntPtr dev,
double distance;
pbd = GetBarrierDevice(c, dev->id);
+ if (!pbd)
+ continue;
+
if (pbd->seen)
continue;
@@ -448,6 +452,9 @@ input_constrain_cursor(DeviceIntPtr dev, ScreenPtr screen,
nearest = &c->barrier;
pbd = GetBarrierDevice(c, master->id);
+ if (!pbd)
+ continue;
+
new_sequence = !pbd->hit;
pbd->seen = TRUE;
@@ -488,6 +495,9 @@ input_constrain_cursor(DeviceIntPtr dev, ScreenPtr screen,
int flags = 0;
pbd = GetBarrierDevice(c, master->id);
+ if (!pbd)
+ continue;
+
pbd->seen = FALSE;
if (!pbd->hit)
continue;
@@ -682,6 +692,9 @@ BarrierFreeBarrier(void *data, XID id)
continue;
pbd = GetBarrierDevice(c, dev->id);
+ if (!pbd)
+ continue;
+
if (!pbd->hit)
continue;
@@ -741,6 +754,8 @@ static void remove_master_func(void *res, XID id, void *devid)
barrier = container_of(b, struct PointerBarrierClient, barrier);
pbd = GetBarrierDevice(barrier, *deviceid);
+ if (!pbd)
+ return;
if (pbd->hit) {
BarrierEvent ev = {
@@ -905,6 +920,10 @@ ProcXIBarrierReleasePointer(ClientPtr client)
barrier = container_of(b, struct PointerBarrierClient, barrier);
pbd = GetBarrierDevice(barrier, dev->id);
+ if (!pbd) {
+ client->errorValue = dev->id;
+ return BadDevice;
+ }
if (pbd->barrier_event_id == event_id)
pbd->release_event_id = event_id;
--
GitLab

View File

@@ -0,0 +1,66 @@
From c1ff84bef2569b4ba4be59323cf575d1798ba9be Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Tue, 17 Dec 2024 15:19:45 +0100
Subject: [PATCH] composite: Handle failure to redirect in compRedirectWindow()
The function compCheckRedirect() may fail if it cannot allocate the
backing pixmap.
In that case, compRedirectWindow() will return a BadAlloc error.
However that failure code path will shortcut the validation of the
window tree marked just before, which leaves the validate data partly
initialized.
That causes a use of uninitialized pointer later.
The fix is to not shortcut the call to compHandleMarkedWindows() even in
the case of compCheckRedirect() returning an error.
CVE-2025-26599, ZDI-CAN-25851
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/c1ff84be]
CVE: CVE-2025-26599
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
---
composite/compalloc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/composite/compalloc.c b/composite/compalloc.c
index eaabf0d..0bbbc55 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -140,6 +140,7 @@ compRedirectWindow(ClientPtr pClient, WindowPtr pWin, int update)
CompScreenPtr cs = GetCompScreen(pWin->drawable.pScreen);
WindowPtr pLayerWin;
Bool anyMarked = FALSE;
+ int status = Success;
if (pWin == cs->pOverlayWin) {
return Success;
@@ -218,13 +219,13 @@ compRedirectWindow(ClientPtr pClient, WindowPtr pWin, int update)
if (!compCheckRedirect(pWin)) {
FreeResource(ccw->id, RT_NONE);
- return BadAlloc;
+ status = BadAlloc;
}
if (anyMarked)
compHandleMarkedWindows(pWin, pLayerWin);
- return Success;
+ return status;
}
void
--
2.25.1

View File

@@ -0,0 +1,129 @@
From b07192a8bedb90b039dc0f70ae69daf047ff9598 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 13 Jan 2025 16:09:43 +0100
Subject: [PATCH] composite: initialize border clip even when pixmap alloc
fails
If it fails to allocate the pixmap, the function compAllocPixmap() would
return early and leave the borderClip region uninitialized, which may
lead to the use of uninitialized value as reported by valgrind:
Conditional jump or move depends on uninitialised value(s)
at 0x4F9B33: compClipNotify (compwindow.c:317)
by 0x484FC9: miComputeClips (mivaltree.c:476)
by 0x48559A: miValidateTree (mivaltree.c:679)
by 0x4F0685: MapWindow (window.c:2693)
by 0x4A344A: ProcMapWindow (dispatch.c:922)
by 0x4A25B5: Dispatch (dispatch.c:560)
by 0x4B082A: dix_main (main.c:282)
by 0x429233: main (stubmain.c:34)
Uninitialised value was created by a heap allocation
at 0x4841866: malloc (vg_replace_malloc.c:446)
by 0x4F47BC: compRedirectWindow (compalloc.c:171)
by 0x4FA8AD: compCreateWindow (compwindow.c:592)
by 0x4EBB89: CreateWindow (window.c:925)
by 0x4A2E6E: ProcCreateWindow (dispatch.c:768)
by 0x4A25B5: Dispatch (dispatch.c:560)
by 0x4B082A: dix_main (main.c:282)
by 0x429233: main (stubmain.c:34)
Conditional jump or move depends on uninitialised value(s)
at 0x48EEDBC: pixman_region_translate (pixman-region.c:2233)
by 0x4F9255: RegionTranslate (regionstr.h:312)
by 0x4F9B7E: compClipNotify (compwindow.c:319)
by 0x484FC9: miComputeClips (mivaltree.c:476)
by 0x48559A: miValidateTree (mivaltree.c:679)
by 0x4F0685: MapWindow (window.c:2693)
by 0x4A344A: ProcMapWindow (dispatch.c:922)
by 0x4A25B5: Dispatch (dispatch.c:560)
by 0x4B082A: dix_main (main.c:282)
by 0x429233: main (stubmain.c:34)
Uninitialised value was created by a heap allocation
at 0x4841866: malloc (vg_replace_malloc.c:446)
by 0x4F47BC: compRedirectWindow (compalloc.c:171)
by 0x4FA8AD: compCreateWindow (compwindow.c:592)
by 0x4EBB89: CreateWindow (window.c:925)
by 0x4A2E6E: ProcCreateWindow (dispatch.c:768)
by 0x4A25B5: Dispatch (dispatch.c:560)
by 0x4B082A: dix_main (main.c:282)
by 0x429233: main (stubmain.c:34)
Conditional jump or move depends on uninitialised value(s)
at 0x48EEE33: UnknownInlinedFun (pixman-region.c:2241)
by 0x48EEE33: pixman_region_translate (pixman-region.c:2225)
by 0x4F9255: RegionTranslate (regionstr.h:312)
by 0x4F9B7E: compClipNotify (compwindow.c:319)
by 0x484FC9: miComputeClips (mivaltree.c:476)
by 0x48559A: miValidateTree (mivaltree.c:679)
by 0x4F0685: MapWindow (window.c:2693)
by 0x4A344A: ProcMapWindow (dispatch.c:922)
by 0x4A25B5: Dispatch (dispatch.c:560)
by 0x4B082A: dix_main (main.c:282)
by 0x429233: main (stubmain.c:34)
Uninitialised value was created by a heap allocation
at 0x4841866: malloc (vg_replace_malloc.c:446)
by 0x4F47BC: compRedirectWindow (compalloc.c:171)
by 0x4FA8AD: compCreateWindow (compwindow.c:592)
by 0x4EBB89: CreateWindow (window.c:925)
by 0x4A2E6E: ProcCreateWindow (dispatch.c:768)
by 0x4A25B5: Dispatch (dispatch.c:560)
by 0x4B082A: dix_main (main.c:282)
by 0x429233: main (stubmain.c:34)
Fix compAllocPixmap() to initialize the border clip even if the creation
of the backing pixmap has failed, to avoid depending later on
uninitialized border clip values.
Related to CVE-2025-26599, ZDI-CAN-25851
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/b07192a8]
CVE: CVE-2025-26599
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
---
composite/compalloc.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/composite/compalloc.c b/composite/compalloc.c
index 7cf7351e00..4a1243170d 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -605,9 +605,12 @@ compAllocPixmap(WindowPtr pWin)
int h = pWin->drawable.height + (bw << 1);
PixmapPtr pPixmap = compNewPixmap(pWin, x, y, w, h);
CompWindowPtr cw = GetCompWindow(pWin);
+ Bool status;
- if (!pPixmap)
- return FALSE;
+ if (!pPixmap) {
+ status = FALSE;
+ goto out;
+ }
if (cw->update == CompositeRedirectAutomatic)
pWin->redirectDraw = RedirectDrawAutomatic;
else
@@ -621,14 +624,16 @@ compAllocPixmap(WindowPtr pWin)
DamageRegister(&pWin->drawable, cw->damage);
cw->damageRegistered = TRUE;
}
+ status = TRUE;
+out:
/* Make sure our borderClip is up to date */
RegionUninit(&cw->borderClip);
RegionCopy(&cw->borderClip, &pWin->borderClip);
cw->borderClipX = pWin->drawable.x;
cw->borderClipY = pWin->drawable.y;
- return TRUE;
+ return status;
}
void
--
GitLab

View File

@@ -0,0 +1,68 @@
From 6e0f332ba4c8b8c9a9945dc9d7989bfe06f80e14 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 16 Dec 2024 16:18:04 +0100
Subject: [PATCH] dix: Dequeue pending events on frozen device on removal
When a device is removed while still frozen, the events queued for that
device remain while the device itself is freed.
As a result, replaying the events will cause a use after free.
To avoid the issue, make sure to dequeue and free any pending events on
a frozen device when removed.
CVE-2025-26600, ZDI-CAN-25871
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/6e0f332b]
CVE: CVE-2025-26600
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
---
dix/devices.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/dix/devices.c b/dix/devices.c
index 1516147..459f1ed 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -962,6 +962,23 @@ FreeAllDeviceClasses(ClassesPtr classes)
}
+static void
+FreePendingFrozenDeviceEvents(DeviceIntPtr dev)
+{
+ QdEventPtr qe, tmp;
+
+ if (!dev->deviceGrab.sync.frozen)
+ return;
+
+ /* Dequeue any frozen pending events */
+ xorg_list_for_each_entry_safe(qe, tmp, &syncEvents.pending, next) {
+ if (qe->device == dev) {
+ xorg_list_del(&qe->next);
+ free(qe);
+ }
+ }
+}
+
/**
* Close down a device and free all resources.
* Once closed down, the driver will probably not expect you that you'll ever
@@ -1026,6 +1043,7 @@ CloseDevice(DeviceIntPtr dev)
free(dev->last.touches[j].valuators);
free(dev->last.touches);
dev->config_info = NULL;
+ FreePendingFrozenDeviceEvents(dev);
dixFreePrivates(dev->devPrivates, PRIVATE_DEVICE);
free(dev);
}
--
2.25.1

View File

@@ -0,0 +1,71 @@
From 16a1242d0ffc7f45ed3c595ee7564b5c04287e0b Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 20 Jan 2025 16:52:01 +0100
Subject: [PATCH] sync: Do not let sync objects uninitialized
When changing an alarm, the change mask values are evaluated one after
the other, changing the trigger values as requested and eventually,
SyncInitTrigger() is called.
SyncInitTrigger() will evaluate the XSyncCACounter first and may free
the existing sync object.
Other changes are then evaluated and may trigger an error and an early
return, not adding the new sync object.
This can be used to cause a use after free when the alarm eventually
triggers.
To avoid the issue, delete the existing sync object as late as possible
only once we are sure that no further error will cause an early exit.
CVE-2025-26601, ZDI-CAN-25870
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/16a1242d]
CVE: CVE-2025-26601
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
---
Xext/sync.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/Xext/sync.c b/Xext/sync.c
index ee0010e657..585cfa6f68 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -360,11 +360,6 @@ SyncInitTrigger(ClientPtr client, SyncTrigger * pTrigger, XID syncObject,
client->errorValue = syncObject;
return rc;
}
- if (pSync != pTrigger->pSync) { /* new counter for trigger */
- SyncDeleteTriggerFromSyncObject(pTrigger);
- pTrigger->pSync = pSync;
- newSyncObject = TRUE;
- }
}
/* if system counter, ask it what the current value is */
@@ -432,6 +427,14 @@ SyncInitTrigger(ClientPtr client, SyncTrigger * pTrigger, XID syncObject,
}
}
+ if (changes & XSyncCACounter) {
+ if (pSync != pTrigger->pSync) { /* new counter for trigger */
+ SyncDeleteTriggerFromSyncObject(pTrigger);
+ pTrigger->pSync = pSync;
+ newSyncObject = TRUE;
+ }
+ }
+
/* we wait until we're sure there are no errors before registering
* a new counter on a trigger
*/
--
GitLab

View File

@@ -0,0 +1,85 @@
From f52cea2f93a0c891494eb3334894442a92368030 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 20 Jan 2025 16:54:30 +0100
Subject: [PATCH] sync: Check values before applying changes
In SyncInitTrigger(), we would set the CheckTrigger function before
validating the counter value.
As a result, if the counter value overflowed, we would leave the
function SyncInitTrigger() with the CheckTrigger applied but without
updating the trigger object.
To avoid that issue, move the portion of code checking for the trigger
check value before updating the CheckTrigger function.
Related to CVE-2025-26601, ZDI-CAN-25870
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/f52cea2f]
CVE: CVE-2025-26601
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
---
Xext/sync.c | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/Xext/sync.c b/Xext/sync.c
index 585cfa6f68..10302160fb 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -381,6 +381,24 @@ SyncInitTrigger(ClientPtr client, SyncTrigger * pTrigger, XID syncObject,
}
}
+ if (changes & (XSyncCAValueType | XSyncCAValue)) {
+ if (pTrigger->value_type == XSyncAbsolute)
+ pTrigger->test_value = pTrigger->wait_value;
+ else { /* relative */
+ Bool overflow;
+
+ if (pCounter == NULL)
+ return BadMatch;
+
+ overflow = checked_int64_add(&pTrigger->test_value,
+ pCounter->value, pTrigger->wait_value);
+ if (overflow) {
+ client->errorValue = pTrigger->wait_value >> 32;
+ return BadValue;
+ }
+ }
+ }
+
if (changes & XSyncCATestType) {
if (pSync && SYNC_FENCE == pSync->type) {
@@ -409,24 +427,6 @@ SyncInitTrigger(ClientPtr client, SyncTrigger * pTrigger, XID syncObject,
}
}
- if (changes & (XSyncCAValueType | XSyncCAValue)) {
- if (pTrigger->value_type == XSyncAbsolute)
- pTrigger->test_value = pTrigger->wait_value;
- else { /* relative */
- Bool overflow;
-
- if (pCounter == NULL)
- return BadMatch;
-
- overflow = checked_int64_add(&pTrigger->test_value,
- pCounter->value, pTrigger->wait_value);
- if (overflow) {
- client->errorValue = pTrigger->wait_value >> 32;
- return BadValue;
- }
- }
- }
-
if (changes & XSyncCACounter) {
if (pSync != pTrigger->pSync) { /* new counter for trigger */
SyncDeleteTriggerFromSyncObject(pTrigger);
--
GitLab

View File

@@ -0,0 +1,52 @@
From 8cbc90c8817306af75a60f494ec9dbb1061e50db Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 20 Jan 2025 17:06:07 +0100
Subject: [PATCH] sync: Do not fail SyncAddTriggerToSyncObject()
We do not want to return a failure at the very last step in
SyncInitTrigger() after having all changes applied.
SyncAddTriggerToSyncObject() must not fail on memory allocation, if the
allocation of the SyncTriggerList fails, trigger a FatalError() instead.
Related to CVE-2025-26601, ZDI-CAN-25870
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/8cbc90c8]
CVE: CVE-2025-26601
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
---
Xext/sync.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/Xext/sync.c b/Xext/sync.c
index 10302160fb..65f2d43780 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -201,8 +201,8 @@ SyncAddTriggerToSyncObject(SyncTrigger * pTrigger)
return Success;
}
- if (!(pCur = malloc(sizeof(SyncTriggerList))))
- return BadAlloc;
+ /* Failure is not an option, it's succeed or burst! */
+ pCur = XNFalloc(sizeof(SyncTriggerList));
pCur->pTrigger = pTrigger;
pCur->next = pTrigger->pSync->pTriglist;
@@ -439,8 +439,7 @@ SyncInitTrigger(ClientPtr client, SyncTrigger * pTrigger, XID syncObject,
* a new counter on a trigger
*/
if (newSyncObject) {
- if ((rc = SyncAddTriggerToSyncObject(pTrigger)) != Success)
- return rc;
+ SyncAddTriggerToSyncObject(pTrigger);
}
else if (pCounter && IsSystemCounter(pCounter)) {
SyncComputeBracketValues(pCounter);
--
GitLab

View File

@@ -0,0 +1,132 @@
From c285798984c6bb99e454a33772cde23d394d3dcd Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 20 Jan 2025 17:10:31 +0100
Subject: [PATCH] sync: Apply changes last in SyncChangeAlarmAttributes()
SyncChangeAlarmAttributes() would apply the various changes while
checking for errors.
If one of the changes triggers an error, the changes for the trigger,
counter or delta value would remain, possibly leading to inconsistent
changes.
Postpone the actual changes until we're sure nothing else can go wrong.
Related to CVE-2025-26601, ZDI-CAN-25870
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/c2857989]
CVE: CVE-2025-26601
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
---
Xext/sync.c | 42 +++++++++++++++++++++++++++---------------
1 file changed, 27 insertions(+), 15 deletions(-)
diff --git a/Xext/sync.c b/Xext/sync.c
index 65f2d43780..cab73be927 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -830,8 +830,14 @@ SyncChangeAlarmAttributes(ClientPtr client, SyncAlarm * pAlarm, Mask mask,
int status;
XSyncCounter counter;
Mask origmask = mask;
+ SyncTrigger trigger;
+ Bool select_events_changed = FALSE;
+ Bool select_events_value = FALSE;
+ int64_t delta;
- counter = pAlarm->trigger.pSync ? pAlarm->trigger.pSync->id : None;
+ trigger = pAlarm->trigger;
+ delta = pAlarm->delta;
+ counter = trigger.pSync ? trigger.pSync->id : None;
while (mask) {
int index2 = lowbit(mask);
@@ -847,24 +853,24 @@ SyncChangeAlarmAttributes(ClientPtr client, SyncAlarm * pAlarm, Mask mask,
case XSyncCAValueType:
mask &= ~XSyncCAValueType;
/* sanity check in SyncInitTrigger */
- pAlarm->trigger.value_type = *values++;
+ trigger.value_type = *values++;
break;
case XSyncCAValue:
mask &= ~XSyncCAValue;
- pAlarm->trigger.wait_value = ((int64_t)values[0] << 32) | values[1];
+ trigger.wait_value = ((int64_t)values[0] << 32) | values[1];
values += 2;
break;
case XSyncCATestType:
mask &= ~XSyncCATestType;
/* sanity check in SyncInitTrigger */
- pAlarm->trigger.test_type = *values++;
+ trigger.test_type = *values++;
break;
case XSyncCADelta:
mask &= ~XSyncCADelta;
- pAlarm->delta = ((int64_t)values[0] << 32) | values[1];
+ delta = ((int64_t)values[0] << 32) | values[1];
values += 2;
break;
@@ -874,10 +880,8 @@ SyncChangeAlarmAttributes(ClientPtr client, SyncAlarm * pAlarm, Mask mask,
client->errorValue = *values;
return BadValue;
}
- status = SyncEventSelectForAlarm(pAlarm, client,
- (Bool) (*values++));
- if (status != Success)
- return status;
+ select_events_value = (Bool) (*values++);
+ select_events_changed = TRUE;
break;
default:
@@ -886,25 +890,33 @@ SyncChangeAlarmAttributes(ClientPtr client, SyncAlarm * pAlarm, Mask mask,
}
}
+ if (select_events_changed) {
+ status = SyncEventSelectForAlarm(pAlarm, client, select_events_value);
+ if (status != Success)
+ return status;
+ }
+
/* "If the test-type is PositiveComparison or PositiveTransition
* and delta is less than zero, or if the test-type is
* NegativeComparison or NegativeTransition and delta is
* greater than zero, a Match error is generated."
*/
if (origmask & (XSyncCADelta | XSyncCATestType)) {
- if ((((pAlarm->trigger.test_type == XSyncPositiveComparison) ||
- (pAlarm->trigger.test_type == XSyncPositiveTransition))
- && pAlarm->delta < 0)
+ if ((((trigger.test_type == XSyncPositiveComparison) ||
+ (trigger.test_type == XSyncPositiveTransition))
+ && delta < 0)
||
- (((pAlarm->trigger.test_type == XSyncNegativeComparison) ||
- (pAlarm->trigger.test_type == XSyncNegativeTransition))
- && pAlarm->delta > 0)
+ (((trigger.test_type == XSyncNegativeComparison) ||
+ (trigger.test_type == XSyncNegativeTransition))
+ && delta > 0)
) {
return BadMatch;
}
}
/* postpone this until now, when we're sure nothing else can go wrong */
+ pAlarm->delta = delta;
+ pAlarm->trigger = trigger;
if ((status = SyncInitTrigger(client, &pAlarm->trigger, counter, RTCounter,
origmask & XSyncCAAllTrigger)) != Success)
return status;
--
GitLab

View File

@@ -0,0 +1,92 @@
From 0885e0b26225c90534642fe911632ec0779eebee Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Fri, 28 Mar 2025 09:43:52 +0100
Subject: [PATCH] render: Avoid 0 or less animated cursors
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Animated cursors use a series of cursors that the client can set.
By default, the Xserver assumes at least one cursor is specified
while a client may actually pass no cursor at all.
That causes an out-of-bound read creating the animated cursor and a
crash of the Xserver:
| Invalid read of size 8
| at 0x5323F4: AnimCursorCreate (animcur.c:325)
| by 0x52D4C5: ProcRenderCreateAnimCursor (render.c:1817)
| by 0x52DC80: ProcRenderDispatch (render.c:1999)
| by 0x4A1E9D: Dispatch (dispatch.c:560)
| by 0x4B0169: dix_main (main.c:284)
| by 0x4287F5: main (stubmain.c:34)
| Address 0x59aa010 is 0 bytes after a block of size 0 alloc'd
| at 0x48468D3: reallocarray (vg_replace_malloc.c:1803)
| by 0x52D3DA: ProcRenderCreateAnimCursor (render.c:1802)
| by 0x52DC80: ProcRenderDispatch (render.c:1999)
| by 0x4A1E9D: Dispatch (dispatch.c:560)
| by 0x4B0169: dix_main (main.c:284)
| by 0x4287F5: main (stubmain.c:34)
|
| Invalid read of size 2
| at 0x5323F7: AnimCursorCreate (animcur.c:325)
| by 0x52D4C5: ProcRenderCreateAnimCursor (render.c:1817)
| by 0x52DC80: ProcRenderDispatch (render.c:1999)
| by 0x4A1E9D: Dispatch (dispatch.c:560)
| by 0x4B0169: dix_main (main.c:284)
| by 0x4287F5: main (stubmain.c:34)
| Address 0x8 is not stack'd, malloc'd or (recently) free'd
To avoid the issue, check the number of cursors specified and return a
BadValue error in both the proc handler (early) and the animated cursor
creation (as this is a public function) if there is 0 or less cursor.
CVE-2025-49175
This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2024>
CVE: CVE-2025-49175
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/0885e0b26225c90534642fe911632ec0779eebee]
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
---
render/animcur.c | 3 +++
render/render.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/render/animcur.c b/render/animcur.c
index ef27bda..77942d8 100644
--- a/render/animcur.c
+++ b/render/animcur.c
@@ -304,6 +304,9 @@ AnimCursorCreate(CursorPtr *cursors, CARD32 *deltas, int ncursor,
int rc = BadAlloc, i;
AnimCurPtr ac;
+ if (ncursor <= 0)
+ return BadValue;
+
for (i = 0; i < screenInfo.numScreens; i++)
if (!GetAnimCurScreen(screenInfo.screens[i]))
return BadImplementation;
diff --git a/render/render.c b/render/render.c
index 5bc2a20..a8c2da0 100644
--- a/render/render.c
+++ b/render/render.c
@@ -1795,6 +1795,8 @@ ProcRenderCreateAnimCursor(ClientPtr client)
ncursor =
(client->req_len -
(bytes_to_int32(sizeof(xRenderCreateAnimCursorReq)))) >> 1;
+ if (ncursor <= 0)
+ return BadValue;
cursors = xallocarray(ncursor, sizeof(CursorPtr) + sizeof(CARD32));
if (!cursors)
return BadAlloc;
--
2.40.0

View File

@@ -0,0 +1,93 @@
From 03731b326a80b582e48d939fe62cb1e2b10400d9 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 7 Apr 2025 16:13:34 +0200
Subject: [PATCH] os: Do not overflow the integer size with BigRequest
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The BigRequest extension allows requests larger than the 16-bit length
limit.
It uses integers for the request length and checks for the size not to
exceed the maxBigRequestSize limit, but does so after translating the
length to integer by multiplying the given size in bytes by 4.
In doing so, it might overflow the integer size limit before actually
checking for the overflow, defeating the purpose of the test.
To avoid the issue, make sure to check that the request size does not
overflow the maxBigRequestSize limit prior to any conversion.
The caller Dispatch() function however expects the return value to be in
bytes, so we cannot just return the converted value in case of error, as
that would also overflow the integer size.
To preserve the existing API, we use a negative value for the X11 error
code BadLength as the function only return positive values, 0 or -1 and
update the caller Dispatch() function to take that case into account to
return the error code to the offending client.
CVE-2025-49176
This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2024>
CVE: CVE-2025-49176
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/03731b326a80b582e48d939fe62cb1e2b10400d9]
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
---
dix/dispatch.c | 9 +++++----
os/io.c | 4 ++++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/dix/dispatch.c b/dix/dispatch.c
index 9e98d54..20473f1 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -513,9 +513,10 @@ Dispatch(void)
/* now, finally, deal with client requests */
result = ReadRequestFromClient(client);
- if (result <= 0) {
- if (result < 0)
- CloseDownClient(client);
+ if (result == 0)
+ break;
+ else if (result == -1) {
+ CloseDownClient(client);
break;
}
@@ -536,7 +537,7 @@ Dispatch(void)
client->index,
client->requestBuffer);
#endif
- if (result > (maxBigRequestSize << 2))
+ if (result < 0 || result > (maxBigRequestSize << 2))
result = BadLength;
else {
result = XaceHookDispatch(client, client->majorOp);
diff --git a/os/io.c b/os/io.c
index 841a0ee..aeece86 100644
--- a/os/io.c
+++ b/os/io.c
@@ -296,6 +296,10 @@ ReadRequestFromClient(ClientPtr client)
needed = get_big_req_len(request, client);
}
client->req_len = needed;
+ if (needed > MAXINT >> 2) {
+ /* Check for potential integer overflow */
+ return -(BadLength);
+ }
needed <<= 2; /* needed is in bytes now */
}
if (gotnow < needed) {
--
2.40.0

View File

@@ -0,0 +1,38 @@
From 4fc4d76b2c7aaed61ed2653f997783a3714c4fe1 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Wed, 18 Jun 2025 08:39:02 +0200
Subject: [PATCH] os: Check for integer overflow on BigRequest length
Check for another possible integer overflow once we get a complete xReq
with BigRequest.
Related to CVE-2025-49176
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Peter Harris <pharris2@rocketsoftware.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2028>
CVE: CVE-2025-49176
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/4fc4d76b2c7aaed61ed2653f997783a3714c4fe1]
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
---
os/io.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/os/io.c b/os/io.c
index aeece86..67465f9 100644
--- a/os/io.c
+++ b/os/io.c
@@ -395,6 +395,8 @@ ReadRequestFromClient(ClientPtr client)
needed = get_big_req_len(request, client);
}
client->req_len = needed;
+ if (needed > MAXINT >> 2)
+ return -(BadLength);
needed <<= 2;
}
if (gotnow < needed) {
--
2.40.0

View File

@@ -0,0 +1,55 @@
From ab02fb96b1c701c3bb47617d965522c34befa6af Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 28 Apr 2025 10:05:36 +0200
Subject: [PATCH] xfixes: Check request length for SetClientDisconnectMode
The handler of XFixesSetClientDisconnectMode does not check the client
request length.
A client could send a shorter request and read data from a former
request.
Fix the issue by checking the request size matches.
CVE-2025-49177
This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Fixes: e167299f6 - xfixes: Add ClientDisconnectMode
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2024>
CVE: CVE-2025-49177
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/ab02fb96b1c701c3bb47617d965522c34befa6af]
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
---
xfixes/disconnect.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xfixes/disconnect.c b/xfixes/disconnect.c
index 28aac45..d6da1f9 100644
--- a/xfixes/disconnect.c
+++ b/xfixes/disconnect.c
@@ -67,6 +67,7 @@ ProcXFixesSetClientDisconnectMode(ClientPtr client)
ClientDisconnectPtr pDisconnect = GetClientDisconnect(client);
REQUEST(xXFixesSetClientDisconnectModeReq);
+ REQUEST_SIZE_MATCH(xXFixesSetClientDisconnectModeReq);
pDisconnect->disconnect_mode = stuff->disconnect_mode;
@@ -80,7 +81,7 @@ SProcXFixesSetClientDisconnectMode(ClientPtr client)
swaps(&stuff->length);
- REQUEST_AT_LEAST_SIZE(xXFixesSetClientDisconnectModeReq);
+ REQUEST_SIZE_MATCH(xXFixesSetClientDisconnectModeReq);
swapl(&stuff->disconnect_mode);
--
2.40.0

View File

@@ -0,0 +1,50 @@
From d55c54cecb5e83eaa2d56bed5cc4461f9ba318c2 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 28 Apr 2025 10:46:03 +0200
Subject: [PATCH] os: Account for bytes to ignore when sharing input buffer
When reading requests from the clients, the input buffer might be shared
and used between different clients.
If a given client sends a full request with non-zero bytes to ignore,
the bytes to ignore may still be non-zero even though the request is
full, in which case the buffer could be shared with another client who's
request will not be processed because of those bytes to ignore, leading
to a possible hang of the other client request.
To avoid the issue, make sure we have zero bytes to ignore left in the
input request when sharing the input buffer with another client.
CVE-2025-49178
This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2024>
CVE: CVE-2025-49178
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/d55c54cecb5e83eaa2d56bed5cc4461f9ba318c2]
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
---
os/io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/os/io.c b/os/io.c
index 67465f9..f92a40e 100644
--- a/os/io.c
+++ b/os/io.c
@@ -444,7 +444,7 @@ ReadRequestFromClient(ClientPtr client)
*/
gotnow -= needed;
- if (!gotnow)
+ if (!gotnow && !oci->ignoreBytes)
AvailableInput = oc;
if (move_header) {
if (client->req_len < bytes_to_int32(sizeof(xBigReq) - sizeof(xReq))) {
--
2.40.0

View File

@@ -0,0 +1,69 @@
From 9d205323894af62b9726fcbaeb5fc69b3c9f61ba Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 28 Apr 2025 11:47:15 +0200
Subject: [PATCH] record: Check for overflow in
RecordSanityCheckRegisterClients()
The RecordSanityCheckRegisterClients() checks for the request length,
but does not check for integer overflow.
A client might send a very large value for either the number of clients
or the number of protocol ranges that will cause an integer overflow in
the request length computation, defeating the check for request length.
To avoid the issue, explicitly check the number of clients against the
limit of clients (which is much lower than an maximum integer value) and
the number of protocol ranges (multiplied by the record length) do not
exceed the maximum integer value.
This way, we ensure that the final computation for the request length
will not overflow the maximum integer limit.
CVE-2025-49179
This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 2bde9ca49a8fd9a1e6697d5e7ef837870d66f5d4)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2026>
CVE: CVE-2025-49179
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/9d205323894af62b9726fcbaeb5fc69b3c9f61ba]
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
---
record/record.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/record/record.c b/record/record.c
index e123867..018e53f 100644
--- a/record/record.c
+++ b/record/record.c
@@ -45,6 +45,7 @@ and Jim Haggerty of Metheus.
#include "inputstr.h"
#include "eventconvert.h"
#include "scrnintstr.h"
+#include "opaque.h"
#include <stdio.h>
#include <assert.h>
@@ -1298,6 +1299,13 @@ RecordSanityCheckRegisterClients(RecordContextPtr pContext, ClientPtr client,
int i;
XID recordingClient;
+ /* LimitClients is 2048 at max, way less that MAXINT */
+ if (stuff->nClients > LimitClients)
+ return BadValue;
+
+ if (stuff->nRanges > (MAXINT - 4 * stuff->nClients) / SIZEOF(xRecordRange))
+ return BadValue;
+
if (((client->req_len << 2) - SIZEOF(xRecordRegisterClientsReq)) !=
4 * stuff->nClients + SIZEOF(xRecordRange) * stuff->nRanges)
return BadLength;
--
2.40.0

View File

@@ -0,0 +1,45 @@
From 3c3a4b767b16174d3213055947ea7f4f88e10ec6 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Tue, 20 May 2025 15:18:19 +0200
Subject: [PATCH] randr: Check for overflow in RRChangeProviderProperty()
A client might send a request causing an integer overflow when computing
the total size to allocate in RRChangeProviderProperty().
To avoid the issue, check that total length in bytes won't exceed the
maximum integer value.
CVE-2025-49180
This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2024>
CVE: CVE-2025-49180
Upstream-Status: Backport [https://gitlab.freedesktop.org/xorg/xserver/-/commit/3c3a4b767b16174d3213055947ea7f4f88e10ec6]
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
---
randr/rrproviderproperty.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/randr/rrproviderproperty.c b/randr/rrproviderproperty.c
index 90c5a9a..0aa35ad 100644
--- a/randr/rrproviderproperty.c
+++ b/randr/rrproviderproperty.c
@@ -179,7 +179,8 @@ RRChangeProviderProperty(RRProviderPtr provider, Atom property, Atom type,
if (mode == PropModeReplace || len > 0) {
void *new_data = NULL, *old_data = NULL;
-
+ if (total_len > MAXINT / size_in_bytes)
+ return BadValue;
total_size = total_len * size_in_bytes;
new_value.data = (void *) malloc(total_size);
if (!new_value.data && total_size) {
--
2.40.0

View File

@@ -0,0 +1,67 @@
SUMMARY = "XWayland is an X Server that runs under Wayland."
DESCRIPTION = "XWayland is an X Server running as a Wayland client, \
and thus is capable of displaying native X11 client applications in a \
Wayland compositor environment. The goal of XWayland is to facilitate \
the transition from X Window System to Wayland environments, providing \
a way to run unported applications in the meantime."
HOMEPAGE = "https://fedoraproject.org/wiki/Changes/XwaylandStandalone"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://COPYING;md5=5df87950af51ac2c5822094553ea1880"
SRC_URI = "https://www.x.org/archive/individual/xserver/xwayland-${PV}.tar.xz \
file://CVE-2024-9632.patch \
file://CVE-2025-26594-1.patch \
file://CVE-2025-26594-2.patch \
file://CVE-2025-26595.patch \
file://CVE-2025-26596.patch \
file://CVE-2025-26597.patch \
file://CVE-2025-26598.patch \
file://CVE-2025-26599-1.patch \
file://CVE-2025-26599-2.patch \
file://CVE-2025-26600.patch \
file://CVE-2025-26601-1.patch \
file://CVE-2025-26601-2.patch \
file://CVE-2025-26601-3.patch \
file://CVE-2025-26601-4.patch \
file://CVE-2025-49175.patch \
file://CVE-2025-49176-0001.patch \
file://CVE-2025-49176-0002.patch \
file://CVE-2025-49177.patch \
file://CVE-2025-49178.patch \
file://CVE-2025-49179.patch \
file://CVE-2025-49180.patch \
"
SRC_URI[sha256sum] = "33ec7ff2687a59faaa52b9b09aa8caf118e7ecb6aed8953f526a625ff9f4bd90"
UPSTREAM_CHECK_REGEX = "xwayland-(?P<pver>\d+(\.(?!90\d)\d+)+)\.tar"
inherit meson features_check pkgconfig
REQUIRED_DISTRO_FEATURES = "x11 opengl"
DEPENDS += "xorgproto xtrans pixman libxkbfile libxfont2 wayland wayland-native wayland-protocols libdrm libepoxy libxcvt"
OPENGL_PKGCONFIGS = "glx glamor dri3"
PACKAGECONFIG ??= "${XORG_CRYPTO} \
${@bb.utils.contains('DISTRO_FEATURES', 'opengl', '${OPENGL_PKGCONFIGS}', '', d)} \
"
PACKAGECONFIG[dri3] = "-Ddri3=true,-Ddri3=false,libxshmfence"
PACKAGECONFIG[glx] = "-Dglx=true,-Dglx=false,virtual/libgl virtual/libx11"
PACKAGECONFIG[glamor] = "-Dglamor=true,-Dglamor=false,libepoxy virtual/libgbm,libegl"
PACKAGECONFIG[unwind] = "-Dlibunwind=true,-Dlibunwind=false,libunwind"
PACKAGECONFIG[xinerama] = "-Dxinerama=true,-Dxinerama=false"
# Xorg requires a SHA1 implementation, pick one
XORG_CRYPTO ??= "openssl"
PACKAGECONFIG[openssl] = "-Dsha1=libcrypto,,openssl"
PACKAGECONFIG[nettle] = "-Dsha1=libnettle,,nettle"
PACKAGECONFIG[gcrypt] = "-Dsha1=libgcrypt,,libgcrypt"
do_install:append() {
# remove files not needed and clashing with xserver-xorg
rm -rf ${D}/${libdir}/xorg/
}
FILES:${PN} += "${libdir}/xorg/protocol.txt"
RDEPENDS:${PN} += "xkbcomp"