rpms/tigervnc
6
0
Fork 0
Code Issues Pull Requests Releases Activity

Compare commits

...

No commits in common. "c8" and "c8-beta" have entirely different histories.
c8 ... c8-beta

17 changed files with 45 additions and 2159 deletions

1113
SOURCES/tigervnc-add-option-to-force-view-only-remote-connections.patch
View File

File diff suppressed because it is too large Load Diff

29
SOURCES/tigervnc-vncsession-use-bin-sh-when-shell-not-set.patch
View File

@ -1,29 +0,0 @@
From 4db34f73d461b973867ddaf18bf690219229cd7a Mon Sep 17 00:00:00 2001
From: Carlos Santos <casantos@redhat.com>
Date: Thu, 25 Jul 2024 18:39:59 -0300
Subject: [PATCH] vncsession: use /bin/sh if the user shell is not set
An empty shell field in the password file is valid, although not common.
Use /bin/sh in this case, as documented in the passwd(5) man page, since
the vncserver script requires a non-empty SHELL environment variable.
Fixes issue #1786.
Signed-off-by: Carlos Santos <casantos@redhat.com>
---
unix/vncserver/vncsession.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/unix/vncserver/vncsession.c b/unix/vncserver/vncsession.c
index 1ee096c7c..98a0432aa 100644
--- a/unix/vncserver/vncsession.c
+++ b/unix/vncserver/vncsession.c
@@ -545,7 +545,7 @@ run_script(const char *username, const char *display, char **envp)
// Set up some basic environment for the script
setenv("HOME", pwent->pw_dir, 1);
- setenv("SHELL", pwent->pw_shell, 1);
+ setenv("SHELL", *pwent->pw_shell != '\0' ? pwent->pw_shell : "/bin/sh", 1);
setenv("LOGNAME", pwent->pw_name, 1);
setenv("USER", pwent->pw_name, 1);
setenv("USERNAME", pwent->pw_name, 1);

32
SOURCES/xorg-CVE-2024-0229-followup.patch Normal file
View File

@ -0,0 +1,32 @@
From 133e0d651c5d12bf01999d6289e84e224ba77adc Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Mon, 22 Jan 2024 14:22:12 +1000
Subject: [PATCH] dix: fix valuator copy/paste error in the DeviceStateNotify
event
Fixes 219c54b8a3337456ce5270ded6a67bcde53553d5
---
dix/enterleave.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/dix/enterleave.c b/dix/enterleave.c
index 7b7ba1098b..c1e6ac600e 100644
--- a/dix/enterleave.c
+++ b/dix/enterleave.c
@@ -619,11 +619,11 @@ FixDeviceValuator(DeviceIntPtr dev, deviceValuator * ev, ValuatorClassPtr v,
ev->first_valuator = first;
switch (ev->num_valuators) {
case 6:
- ev->valuator2 = v->axisVal[first + 5];
+ ev->valuator5 = v->axisVal[first + 5];
case 5:
- ev->valuator2 = v->axisVal[first + 4];
+ ev->valuator4 = v->axisVal[first + 4];
case 4:
- ev->valuator2 = v->axisVal[first + 3];
+ ev->valuator3 = v->axisVal[first + 3];
case 3:
ev->valuator2 = v->axisVal[first + 2];
case 2:
--
GitLab

46
SOURCES/xorg-CVE-2025-26594-2.patch
View File

@ -1,46 +0,0 @@
From ded614e74e7175927dd2bc5ef69accaf2de29939 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 xserver 2/2] 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>
---
dix/main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/dix/main.c b/dix/main.c
index aa7b020b2..0c57ba605 100644
--- a/dix/main.c
+++ b/dix/main.c
@@ -235,6 +235,8 @@ dix_main(int argc, char *argv[], char *envp[])
defaultCursorFont);
}
+ rootCursor = RefCursor(rootCursor);
+
#ifdef PANORAMIX
/*
* Consolidate window and colourmap information for each screen
@@ -275,6 +277,8 @@ dix_main(int argc, char *argv[], char *envp[])
Dispatch();
+ UnrefCursor(rootCursor);
+
UndisplayDevices();
DisableAllDevices();
--
2.48.1

52
SOURCES/xorg-CVE-2025-26594.patch
View File

@ -1,52 +0,0 @@
From efca605c45ff51b57f136222b966ce1d610ebc33 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Wed, 27 Nov 2024 11:27:05 +0100
Subject: [PATCH xserver 1/2] Cursor: Refuse to free the root cursor
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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 Dänzer
<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>
---
dix/dispatch.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/dix/dispatch.c b/dix/dispatch.c
index 5f7cfe02d..d1241fa96 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -3039,6 +3039,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.48.1

60
SOURCES/xorg-CVE-2025-26595.patch
View File

@ -1,60 +0,0 @@
From 98602942c143075ab7464f917e0fc5d31ce28c3f Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Wed, 27 Nov 2024 14:41:45 +0100
Subject: [PATCH xserver] 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>
---
xkb/xkbtext.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/xkb/xkbtext.c b/xkb/xkbtext.c
index 018466420..93262528b 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);
--
2.48.1

44
SOURCES/xorg-CVE-2025-26596.patch
View File

@ -1,44 +0,0 @@
From b41f6fce201e77a174550935330e2f7772d4adf9 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Thu, 28 Nov 2024 11:49:34 +0100
Subject: [PATCH xserver] 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>
---
xkb/xkb.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xkb/xkb.c b/xkb/xkb.c
index 85659382d..744dba63d 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;
--
2.48.1

41
SOURCES/xorg-CVE-2025-26597.patch
View File

@ -1,41 +0,0 @@
From c5114475db18f29d639537d60e135bdfc11a5d3a Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Thu, 28 Nov 2024 14:09:04 +0100
Subject: [PATCH xserver] 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>
---
xkb/XKBMisc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xkb/XKBMisc.c b/xkb/XKBMisc.c
index abbfed90e..fd180fad2 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;
}
--
2.48.1

115
SOURCES/xorg-CVE-2025-26598.patch
View File

@ -1,115 +0,0 @@
From 0f5ea9d269ac6225bcb302a1ec0f58878114da9f Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 16 Dec 2024 11:25:11 +0100
Subject: [PATCH xserver] 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>
---
Xi/xibarriers.c | 27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/Xi/xibarriers.c b/Xi/xibarriers.c
index 80c4b5981..28bc0a24f 100644
--- a/Xi/xibarriers.c
+++ b/Xi/xibarriers.c
@@ -131,14 +131,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;
}
@@ -339,6 +340,9 @@ barrier_find_nearest(BarrierScreenPtr cs, DeviceIntPtr dev,
double distance;
pbd = GetBarrierDevice(c, dev->id);
+ if (!pbd)
+ continue;
+
if (pbd->seen)
continue;
@@ -447,6 +451,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;
@@ -487,6 +494,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;
@@ -681,6 +691,9 @@ BarrierFreeBarrier(void *data, XID id)
continue;
pbd = GetBarrierDevice(c, dev->id);
+ if (!pbd)
+ continue;
+
if (!pbd->hit)
continue;
@@ -740,6 +753,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 = {
@@ -904,6 +919,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;
--
2.48.1

124
SOURCES/xorg-CVE-2025-26599-2.patch
View File

@ -1,124 +0,0 @@
From f5ce639ff9d3af05e79efce6c51e084352d28ed1 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 13 Jan 2025 16:09:43 +0100
Subject: [PATCH xserver 2/2] 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>
---
composite/compalloc.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/composite/compalloc.c b/composite/compalloc.c
index ecb1b6147..d1342799b 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
--
2.48.1

62
SOURCES/xorg-CVE-2025-26599.patch
View File

@ -1,62 +0,0 @@
From 10a24e364ac15983051d0bb90817c88bbe107036 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Tue, 17 Dec 2024 15:19:45 +0100
Subject: [PATCH xserver 1/2] 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>
---
composite/compalloc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/composite/compalloc.c b/composite/compalloc.c
index e52c009bd..ecb1b6147 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -138,6 +138,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;
@@ -216,13 +217,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.48.1

64
SOURCES/xorg-CVE-2025-26600.patch
View File

@ -1,64 +0,0 @@
From 70ad5d36ae80f6e5a436eabfee642c2c013e51cc Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 16 Dec 2024 16:18:04 +0100
Subject: [PATCH xserver] 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>
---
dix/devices.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/dix/devices.c b/dix/devices.c
index 969819534..740390207 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -966,6 +966,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
@@ -1030,6 +1047,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.48.1

80
SOURCES/xorg-CVE-2025-26601-2.patch
View File

@ -1,80 +0,0 @@
From 7dc3f11abb51cad8a59ecbff5278c8c8a318df41 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 20 Jan 2025 16:54:30 +0100
Subject: [PATCH xserver 2/4] 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>
---
Xext/sync.c | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/Xext/sync.c b/Xext/sync.c
index 4267d3af6..4eab5a6ac 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -351,6 +351,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) {
@@ -379,24 +397,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);
--
2.48.1

47
SOURCES/xorg-CVE-2025-26601-3.patch
View File

@ -1,47 +0,0 @@
From 4ccaa5134482b6be9c9a7f0b66cd221ef325d082 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 20 Jan 2025 17:06:07 +0100
Subject: [PATCH xserver 3/4] 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>
---
Xext/sync.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/Xext/sync.c b/Xext/sync.c
index 4eab5a6ac..c36de1a2e 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -200,8 +200,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;
@@ -409,8 +409,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);
--
2.48.1

128
SOURCES/xorg-CVE-2025-26601-4.patch
View File

@ -1,128 +0,0 @@
From f0984082067f79b45383fa1eb889c6a901667331 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 20 Jan 2025 17:10:31 +0100
Subject: [PATCH xserver 4/4] 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>
---
Xext/sync.c | 42 +++++++++++++++++++++++++++---------------
1 file changed, 27 insertions(+), 15 deletions(-)
diff --git a/Xext/sync.c b/Xext/sync.c
index c36de1a2e..e282e6657 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -800,8 +800,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;
+ 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);
@@ -817,24 +823,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;
@@ -844,10 +850,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:
@@ -856,25 +860,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;
--
2.48.1

66
SOURCES/xorg-CVE-2025-26601.patch
View File

@ -1,66 +0,0 @@
From 573a2265aacfeaddcc1bb001905a6f7d4fa15ee6 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 20 Jan 2025 16:52:01 +0100
Subject: [PATCH xserver 1/4] 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>
---
Xext/sync.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/Xext/sync.c b/Xext/sync.c
index b6417b3b0..4267d3af6 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -330,11 +330,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 */
@@ -402,6 +397,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
*/
--
2.48.1

101
SPECS/tigervnc.spec
View File

@ -5,7 +5,7 @@
Name: tigervnc
Version: 1.13.1
Release: 15%{?dist}
Release: 8%{?dist}
Summary: A TigerVNC remote display system
%global _hardened_build 1
@ -29,8 +29,6 @@ Patch3: tigervnc-dont-install-appstream-metadata-file.patch
# Upstream patches
Patch50: tigervnc-support-username-alias-in-plainusers.patch
Patch51: tigervnc-use-dup-to-get-available-fd-for-inetd.patch
Patch52: tigervnc-add-option-to-force-view-only-remote-connections.patch
Patch53: tigervnc-vncsession-use-bin-sh-when-shell-not-set.patch
# Upstreamable patches
Patch80: tigervnc-dont-get-pointer-position-for-floating-device.patch
@ -41,19 +39,9 @@ Patch100: tigervnc-xserver120.patch
Patch101: 0001-rpath-hack.patch
# XServer patches
Patch200: xorg-CVE-2025-26594.patch
Patch201: xorg-CVE-2025-26594-2.patch
Patch202: xorg-CVE-2025-26595.patch
Patch203: xorg-CVE-2025-26596.patch
Patch204: xorg-CVE-2025-26597.patch
Patch205: xorg-CVE-2025-26598.patch
Patch206: xorg-CVE-2025-26599.patch
Patch207: xorg-CVE-2025-26599-2.patch
Patch208: xorg-CVE-2025-26600.patch
Patch209: xorg-CVE-2025-26601.patch
Patch210: xorg-CVE-2025-26601-2.patch
Patch211: xorg-CVE-2025-26601-3.patch
Patch212: xorg-CVE-2025-26601-4.patch
# CVE-2024-0229
# https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1251
Patch200: xorg-CVE-2024-0229-followup.patch
BuildRequires: make
BuildRequires: gcc-c++
@ -199,35 +187,21 @@ pushd unix/xserver
for all in `find . -type f -perm -001`; do
chmod -x "$all"
done
%patch -P100 -p1 -b .xserver120-rebased
%patch -P101 -p1 -b .rpath
%patch -P200 -p1 -b .xorg-CVE-2025-26594
%patch -P201 -p1 -b .xorg-CVE-2025-26594-2
%patch -P202 -p1 -b .xorg-CVE-2025-26595
%patch -P203 -p1 -b .xorg-CVE-2025-26596
%patch -P204 -p1 -b .xorg-CVE-2025-26597
%patch -P205 -p1 -b .xorg-CVE-2025-26598
%patch -P206 -p1 -b .xorg-CVE-2025-26599
%patch -P207 -p1 -b .xorg-CVE-2025-26599-2
%patch -P208 -p1 -b .xorg-CVE-2025-26600
%patch -P209 -p1 -b .xorg-CVE-2025-26601
%patch -P210 -p1 -b .xorg-CVE-2025-26601-2
%patch -P211 -p1 -b .xorg-CVE-2025-26601-3
%patch -P212 -p1 -b .xorg-CVE-2025-26601-4
%patch100 -p1 -b .xserver120-rebased
%patch101 -p1 -b .rpath
%patch200 -p1 -b .xorg-CVE-2024-0229-followup
popd
%patch -P1 -p1 -b .use-gnome-as-default-session
%patch -P2 -p1 -b .vncsession-restore-script-systemd-service
%patch -P3 -p1 -b .dont-install-appstream-metadata-file.patch
%patch1 -p1 -b .use-gnome-as-default-session
%patch2 -p1 -b .vncsession-restore-script-systemd-service
%patch3 -p1 -b .dont-install-appstream-metadata-file.patch
# Upstream patches
%patch -P50 -p1 -b .support-username-alias-in-plainusers
%patch -P51 -p1 -b .use-dup-to-get-available-fd-for-inetd
%patch -P52 -p1 -b .add-option-to-force-view-only-remote-connections
%patch -P53 -p1 -b .tigervnc-vncsession-use-bin-sh-when-shell-not-set
%patch50 -p1 -b .support-username-alias-in-plainusers
%patch51 -p1 -b .use-dup-to-get-available-fd-for-inetd
# Upstreamable patches
%patch -P80 -p1 -b .dont-get-pointer-position-for-floating-device
%patch80 -p1 -b .dont-get-pointer-position-for-floating-device
%build
%ifarch sparcv9 sparc64 s390 s390x
@ -382,55 +356,6 @@ fi
%ghost %verify(not md5 size mode mtime) %{_sharedstatedir}/selinux/%{selinuxtype}/active/modules/200/%{modulename}
%changelog
* Wed Feb 26 2025 Jan Grulich <jgrulich@redhat.com> - 1.13.1-15
- Fix CVE-2025-26594 xorg-x11-server Use-after-free of the root cursor
Resolves: RHEL-79397
- Fix CVE-2025-26595 xorg-x11-server Buffer overflow in XkbVModMaskText()
Resolves: RHEL-79401
- Fix CVE-2025-26596 xorg-x11-server Heap overflow in XkbWriteKeySyms()
Resolves: RHEL-79386
- Fix CVE-2025-26597 xorg-x11-server Buffer overflow in XkbChangeTypesOfKey()
Resolves: RHEL-79380
- Fix CVE-2025-26598 xorg-x11-server Out-of-bounds write in CreatePointerBarrierClient()
Resolves: RHEL-79369
- Fix CVE-2025-26599 xorg-x11-server Use of uninitialized pointer in compRedirectWindow()
Resolves: RHEL-79364
- Fix CVE-2025-26600 xorg-x11-server Use-after-free in PlayReleasedEvents()
Resolves: RHEL-79360
- Fix CVE-2025-26601 xorg-x11-server Use-after-free in SyncInitTrigger()
Resolves: RHEL-79348
* Thu Oct 31 2024 Jan Grulich <jgrulich@redhat.com> - 1.13.1-14
- Fix CVE-2024-9632: xorg-x11-server: heap-based buffer overflow privilege escalation vulnerability
Resolves: RHEL-61999
* Mon Aug 05 2024 Jan Grulich <jgrulich@redhat.com> - 1.13.1-13
- vncsession: use /bin/sh if the user shell is not set
Resolves: RHEL-52827
* Fri Jul 12 2024 Jan Grulich <jgrulich@redhat.com> - 1.13.1-12
- Fix FTBS: drop already applied Xorg patches
Resolves: RHEL-46696
* Tue May 28 2024 Jan Grulich <jgrulich@redhat.com> - 1.13.1-11
- vncconfig: add option to force view-only remote client connections
Resolves: RHEL-11908
* Mon Apr 15 2024 Jan Grulich <jgrulich@redhat.com> - 1.13.1-10
- Drop patches that are already part of xorg-x11-server
Resolves: RHEL-30755
Resolves: RHEL-30767
Resolves: RHEL-30761
* Thu Apr 04 2024 Jan Grulich <jgrulich@redhat.com> - 1.13.1-9
- Fix CVE-2024-31080 tigervnc: xorg-x11-server: Heap buffer overread/data leakage in ProcXIGetSelectedEvents
Resolves: RHEL-30755
- Fix CVE-2024-31083 tigervnc: xorg-x11-server: User-after-free in ProcRenderAddGlyphs
Resolves: RHEL-30767
- Fix CVE-2024-31081 tigervnc: xorg-x11-server: Heap buffer overread/data leakage in ProcXIPassiveGrabDevice
Resolves: RHEL-30761
* Wed Feb 07 2024 Jan Grulich <jgrulich@redhat.com> - 1.13.1-8
- Fix copy/paste error in the DeviceStateNotify
Resolves: RHEL-20530