rpms/xorg-x11-server
7
0
Fork 0
Code Issues Pull Requests Releases Activity

import CS xorg-x11-server-1.20.11-33.el9

Browse Source
This commit is contained in:
AlmaLinux RelEng Bot 2026-03-30 11:15:26 -04:00
parent f5aa3b2823
commit 34c62bd3fc
14 changed files with 915 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

101
SOURCES/0001-dix-Force-update-LEDs-after-device-state-update-in-E.patch Normal file
View File

@ -0,0 +1,101 @@
From 9c27c756438a62fdd768147d753b4c5fc731247b Mon Sep 17 00:00:00 2001
From: Yao Wei <mwei@lxde.org>
Date: Tue, 21 Feb 2023 03:43:05 +0000
Subject: [PATCH xserver] dix: Force update LEDs after device state update in
EnableDevice
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This is to make sure the hardware gets the device states regardless
whether the internal state has changed or not, to overcome situations
that device LEDs are out of sync e.g. switching between VTs.
Signed-off-by: Yao Wei (魏銘廷) <yao.wei@canonical.com>
(cherry picked from commit 7ce57e179b257f35e447971f4fb6614e3360762a)
---
dix/devices.c | 4 ++++
include/xkbsrv.h | 2 ++
xkb/xkbLEDs.c | 38 ++++++++++++++++++++++++++++++++++++++
3 files changed, 44 insertions(+)
diff --git a/dix/devices.c b/dix/devices.c
index 00c453980..5629d9cf1 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -426,6 +426,10 @@ EnableDevice(DeviceIntPtr dev, BOOL sendevent)
if (!IsMaster(dev) && !IsFloating(dev))
XkbPushLockedStateToSlaves(GetMaster(dev, MASTER_KEYBOARD), 0, 0);
+
+ /* Now make sure our LEDs are in sync with the locked state */
+ XkbForceUpdateDeviceLEDs(dev);
+
RecalculateMasterButtons(dev);
/* initialise an idle timer for this device*/
diff --git a/include/xkbsrv.h b/include/xkbsrv.h
index fbb5427e1..90a5e5327 100644
--- a/include/xkbsrv.h
+++ b/include/xkbsrv.h
@@ -505,6 +505,8 @@ extern _X_EXPORT void XkbUpdateIndicators(DeviceIntPtr /* keybd */ ,
XkbEventCausePtr /* cause */
);
+extern void XkbForceUpdateDeviceLEDs(DeviceIntPtr /* keybd */);
+
extern _X_EXPORT void XkbUpdateAllDeviceIndicators(XkbChangesPtr /* changes */,
XkbEventCausePtr /* cause */
);
diff --git a/xkb/xkbLEDs.c b/xkb/xkbLEDs.c
index 5792d9fb7..3fb8fc526 100644
--- a/xkb/xkbLEDs.c
+++ b/xkb/xkbLEDs.c
@@ -435,6 +435,44 @@ XkbUpdateIndicators(DeviceIntPtr dev,
/***====================================================================***/
+ /*
+ * void
+ * XkbForceUpdateDeviceLEDs(DeviceIntPtr dev)
+ *
+ * Force update LED states to the hardware from the device state
+ * specified by 'dev'.
+ *
+ * If 'dev' is a master device, this function will also force update
+ * its slave devices.
+ *
+ * Used if the actual LED state was externally set and need to push
+ * current state to the hardware e.g. switching between VTs.
+ */
+
+void
+XkbForceUpdateDeviceLEDs(DeviceIntPtr dev)
+{
+ DeviceIntPtr master;
+ XkbSrvLedInfoPtr sli;
+
+ if (!dev->key)
+ return;
+
+ sli = XkbFindSrvLedInfo(dev, XkbDfltXIClass, XkbDfltXIId, 0);
+ XkbDDXUpdateDeviceIndicators(dev, sli, sli->effectiveState);
+
+ if (IsMaster(dev)) {
+ master = dev;
+ nt_list_for_each_entry(dev, inputInfo.devices, next) {
+ if (!dev->key || GetMaster(dev, MASTER_KEYBOARD) != master)
+ continue;
+
+ sli = XkbFindSrvLedInfo(dev, XkbDfltXIClass, XkbDfltXIId, 0);
+ XkbDDXUpdateDeviceIndicators(dev, sli, sli->effectiveState);
+ }
+ }
+}
+
/***====================================================================***/
/*
--
2.48.1

88
SOURCES/0001-present-Fix-use-after-free-in-present_create_notifie.patch Normal file
View File

@ -0,0 +1,88 @@
From 4d07b16328bc9c9d4f6c4c1a9a522d64bf09deda Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Wed, 2 Jul 2025 09:46:22 +0200
Subject: [PATCH xserver 1/4] present: Fix use-after-free in
present_create_notifies()
Using the Present extension, if an error occurs while processing and
adding the notifications after presenting a pixmap, the function
present_create_notifies() will clean up and remove the notifications
it added.
However, there are two different code paths that can lead to an error
creating the notify, one being before the notify is being added to the
list, and another one after the notify is added.
When the error occurs before it's been added, it removes the elements up
to the last added element, instead of the actual number of elements
which were added.
As a result, in case of error, as with an invalid window for example, it
leaves a dangling pointer to the last element, leading to a use after
free case later:
| Invalid write of size 8
| at 0x5361D5: present_clear_window_notifies (present_notify.c:42)
| by 0x534A56: present_destroy_window (present_screen.c:107)
| by 0x41E441: xwl_destroy_window (xwayland-window.c:1959)
| by 0x4F9EC9: compDestroyWindow (compwindow.c:622)
| by 0x51EAC4: damageDestroyWindow (damage.c:1592)
| by 0x4FDC29: DbeDestroyWindow (dbe.c:1291)
| by 0x4EAC55: FreeWindowResources (window.c:1023)
| by 0x4EAF59: DeleteWindow (window.c:1091)
| by 0x4DE59A: doFreeResource (resource.c:890)
| by 0x4DEFB2: FreeClientResources (resource.c:1156)
| by 0x4A9AFB: CloseDownClient (dispatch.c:3567)
| by 0x5DCC78: ClientReady (connection.c:603)
| Address 0x16126200 is 16 bytes inside a block of size 2,048 free'd
| at 0x4841E43: free (vg_replace_malloc.c:989)
| by 0x5363DD: present_destroy_notifies (present_notify.c:111)
| by 0x53638D: present_create_notifies (present_notify.c:100)
| by 0x5368E9: proc_present_pixmap_common (present_request.c:164)
| by 0x536A7D: proc_present_pixmap (present_request.c:189)
| by 0x536FA9: proc_present_dispatch (present_request.c:337)
| by 0x4A1E4E: Dispatch (dispatch.c:561)
| by 0x4B00F1: dix_main (main.c:284)
| by 0x42879D: main (stubmain.c:34)
| Block was alloc'd at
| at 0x48463F3: calloc (vg_replace_malloc.c:1675)
| by 0x5362A1: present_create_notifies (present_notify.c:81)
| by 0x5368E9: proc_present_pixmap_common (present_request.c:164)
| by 0x536A7D: proc_present_pixmap (present_request.c:189)
| by 0x536FA9: proc_present_dispatch (present_request.c:337)
| by 0x4A1E4E: Dispatch (dispatch.c:561)
| by 0x4B00F1: dix_main (main.c:284)
| by 0x42879D: main (stubmain.c:34)
To fix the issue, count and remove the actual number of notify elements
added in case of error.
CVE-2025-62229, ZDI-CAN-27238
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 5a4286b13f631b66c20f5bc8db7b68211dcbd1d0)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2088>
---
present/present_notify.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/present/present_notify.c b/present/present_notify.c
index 445954998..00b3b68bd 100644
--- a/present/present_notify.c
+++ b/present/present_notify.c
@@ -90,7 +90,7 @@ present_create_notifies(ClientPtr client, int num_notifies, xPresentNotify *x_no
if (status != Success)
goto bail;
- added = i;
+ added++;
}
return Success;
--
2.51.1

89
SOURCES/0001-render-Avoid-0-or-less-animated-cursors.patch Normal file
View File

@ -0,0 +1,89 @@
From 4c8e10312a721aa2f36048388284a2fd4ad97043 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Fri, 28 Mar 2025 09:43:52 +0100
Subject: [PATCH xserver 1/7] 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>
(cherry picked from commit 0885e0b26225c90534642fe911632ec0779eebee)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2025>
---
render/animcur.c | 3 +++
render/render.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/render/animcur.c b/render/animcur.c
index ef27bda27..77942d846 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 456f156d4..e9bbac62d 100644
--- a/render/render.c
+++ b/render/render.c
@@ -1788,6 +1788,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.49.0

63
SOURCES/0001-xfree86-Fix-potentially-NULL-reference-to-platform-d.patch Normal file
View File

@ -0,0 +1,63 @@
From 0d93bbfa2cfacbb73741f8bed0e32fa1a656b928 Mon Sep 17 00:00:00 2001
From: Povilas Kanapickas <povilas@radix.lt>
Date: Fri, 26 Mar 2021 00:51:02 +0200
Subject: [PATCH xserver] xfree86: Fix potentially NULL reference to platform
device's PCI device
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
xf86_platform_devices[i].pdev may be NULL in cases we fail to parse the
busid in config_udev_odev_setup_attribs() (see also [1], [2]) such as
when udev does not give use ID_PATH. This in turn leads to
platform_find_pci_info() being not called and pdev being NULL.
[1]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/993
[2]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1076
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
Signed-off-by: Michel Dänzer <michel@daenzer.net>
---
hw/xfree86/common/xf86platformBus.c | 10 ++++++----
hw/xfree86/os-support/linux/lnx_platform.c | 3 +++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/hw/xfree86/common/xf86platformBus.c b/hw/xfree86/common/xf86platformBus.c
index ee2f3f86a..e43ff69af 100644
--- a/hw/xfree86/common/xf86platformBus.c
+++ b/hw/xfree86/common/xf86platformBus.c
@@ -365,10 +365,12 @@ xf86MergeOutputClassOptions(int entityIndex, void **options)
break;
case BUS_PCI:
for (i = 0; i < xf86_num_platform_devices; i++) {
- if (MATCH_PCI_DEVICES(xf86_platform_devices[i].pdev,
- entity->bus.id.pci)) {
- dev = &xf86_platform_devices[i];
- break;
+ if (xf86_platform_devices[i].pdev) {
+ if (MATCH_PCI_DEVICES(xf86_platform_devices[i].pdev,
+ entity->bus.id.pci)) {
+ dev = &xf86_platform_devices[i];
+ break;
+ }
}
}
break;
diff --git a/hw/xfree86/os-support/linux/lnx_platform.c b/hw/xfree86/os-support/linux/lnx_platform.c
index fe2142182..8a6be97aa 100644
--- a/hw/xfree86/os-support/linux/lnx_platform.c
+++ b/hw/xfree86/os-support/linux/lnx_platform.c
@@ -85,6 +85,9 @@ xf86PlatformDeviceCheckBusID(struct xf86_platform_device *device, const char *bu
bustype = StringToBusType(busid, &id);
if (bustype == BUS_PCI) {
struct pci_device *pPci = device->pdev;
+ if (!pPci)
+ return FALSE;
+
if (xf86ComparePciBusString(busid,
((pPci->domain << 8)
| pPci->bus),
--
2.49.0

91
SOURCES/0002-os-Do-not-overflow-the-integer-size-with-BigRequest.patch Normal file
View File

@ -0,0 +1,91 @@
From a99c927aec4563101f574d0a65cd451dcdd7e012 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 7 Apr 2025 16:13:34 +0200
Subject: [PATCH xserver 2/7] 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>
(cherry picked from commit 03731b326a80b582e48d939fe62cb1e2b10400d9)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2025>
---
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 a33bfaa9e..14ccdc57a 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -447,9 +447,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;
}
@@ -470,7 +471,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 939f51743..a05300869 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.49.0

59
SOURCES/0002-xkb-Make-the-RT_XKBCLIENT-resource-private.patch Normal file
View File

@ -0,0 +1,59 @@
From a1d4f04bbd46957af854bea3b23d0dcb31b38afd Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Wed, 10 Sep 2025 15:55:06 +0200
Subject: [PATCH xserver 2/4] xkb: Make the RT_XKBCLIENT resource private
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Currently, the resource in only available to the xkb.c source file.
In preparation for the next commit, to be able to free the resources
from XkbRemoveResourceClient(), make that variable private instead.
This is related to:
CVE-2025-62230, ZDI-CAN-27545
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: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 99790a2c9205a52fbbec01f21a92c9b7f4ed1d8f)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2088>
---
include/xkbsrv.h | 2 ++
xkb/xkb.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/xkbsrv.h b/include/xkbsrv.h
index bd747856b..d801cd4b8 100644
--- a/include/xkbsrv.h
+++ b/include/xkbsrv.h
@@ -58,6 +58,8 @@ THE USE OR PERFORMANCE OF THIS SOFTWARE.
#include "inputstr.h"
#include "events.h"
+extern RESTYPE RT_XKBCLIENT;
+
typedef struct _XkbInterest {
DeviceIntPtr dev;
ClientPtr client;
diff --git a/xkb/xkb.c b/xkb/xkb.c
index ac154e200..6c102af0a 100644
--- a/xkb/xkb.c
+++ b/xkb/xkb.c
@@ -50,7 +50,7 @@ int XkbKeyboardErrorCode;
CARD32 xkbDebugFlags = 0;
static CARD32 xkbDebugCtrls = 0;
-static RESTYPE RT_XKBCLIENT;
+RESTYPE RT_XKBCLIENT = 0;
/***====================================================================***/
--
2.51.1

35
SOURCES/0003-os-Check-for-integer-overflow-on-BigRequest-length.patch Normal file
View File

@ -0,0 +1,35 @@
From d5b66f2b1f3d9a322261d150e0da4e707a337334 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Wed, 18 Jun 2025 08:39:02 +0200
Subject: [PATCH xserver 3/7] 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>
(cherry picked from commit 4fc4d76b2c7aaed61ed2653f997783a3714c4fe1)
---
os/io.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/os/io.c b/os/io.c
index a05300869..de5b3c921 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.49.0

89
SOURCES/0003-xkb-Free-the-XKB-resource-when-freeing-XkbInterest.patch Normal file
View File

@ -0,0 +1,89 @@
From 1abca0b9b5b019cda32aa92466a760660ebd952d Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Wed, 10 Sep 2025 15:58:57 +0200
Subject: [PATCH xserver 3/4] xkb: Free the XKB resource when freeing
XkbInterest
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
XkbRemoveResourceClient() would free the XkbInterest data associated
with the device, but not the resource associated with it.
As a result, when the client terminates, the resource delete function
gets called and accesses already freed memory:
| Invalid read of size 8
| at 0x5BC0C0: XkbRemoveResourceClient (xkbEvents.c:1047)
| by 0x5B3391: XkbClientGone (xkb.c:7094)
| by 0x4DF138: doFreeResource (resource.c:890)
| by 0x4DFB50: FreeClientResources (resource.c:1156)
| by 0x4A9A59: CloseDownClient (dispatch.c:3550)
| by 0x5E0A53: ClientReady (connection.c:601)
| by 0x5E4FEF: ospoll_wait (ospoll.c:657)
| by 0x5DC834: WaitForSomething (WaitFor.c:206)
| by 0x4A1BA5: Dispatch (dispatch.c:491)
| by 0x4B0070: dix_main (main.c:277)
| by 0x4285E7: main (stubmain.c:34)
| Address 0x1893e278 is 184 bytes inside a block of size 928 free'd
| at 0x4842E43: free (vg_replace_malloc.c:989)
| by 0x49C1A6: CloseDevice (devices.c:1067)
| by 0x49C522: CloseOneDevice (devices.c:1193)
| by 0x49C6E4: RemoveDevice (devices.c:1244)
| by 0x5873D4: remove_master (xichangehierarchy.c:348)
| by 0x587921: ProcXIChangeHierarchy (xichangehierarchy.c:504)
| by 0x579BF1: ProcIDispatch (extinit.c:390)
| by 0x4A1D85: Dispatch (dispatch.c:551)
| by 0x4B0070: dix_main (main.c:277)
| by 0x4285E7: main (stubmain.c:34)
| Block was alloc'd at
| at 0x48473F3: calloc (vg_replace_malloc.c:1675)
| by 0x49A118: AddInputDevice (devices.c:262)
| by 0x4A0E58: AllocDevicePair (devices.c:2846)
| by 0x5866EE: add_master (xichangehierarchy.c:153)
| by 0x5878C2: ProcXIChangeHierarchy (xichangehierarchy.c:493)
| by 0x579BF1: ProcIDispatch (extinit.c:390)
| by 0x4A1D85: Dispatch (dispatch.c:551)
| by 0x4B0070: dix_main (main.c:277)
| by 0x4285E7: main (stubmain.c:34)
To avoid that issue, make sure to free the resources when freeing the
device XkbInterest data.
CVE-2025-62230, ZDI-CAN-27545
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: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 10c94238bdad17c11707e0bdaaa3a9cd54c504be)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2088>
---
xkb/xkbEvents.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xkb/xkbEvents.c b/xkb/xkbEvents.c
index f8f65d4a7..7c669c93e 100644
--- a/xkb/xkbEvents.c
+++ b/xkb/xkbEvents.c
@@ -1055,6 +1055,7 @@ XkbRemoveResourceClient(DevicePtr inDev, XID id)
autoCtrls = interest->autoCtrls;
autoValues = interest->autoCtrlValues;
client = interest->client;
+ FreeResource(interest->resource, RT_XKBCLIENT);
free(interest);
found = TRUE;
}
@@ -1066,6 +1067,7 @@ XkbRemoveResourceClient(DevicePtr inDev, XID id)
autoCtrls = victim->autoCtrls;
autoValues = victim->autoCtrlValues;
client = victim->client;
+ FreeResource(victim->resource, RT_XKBCLIENT);
free(victim);
found = TRUE;
}
--
2.51.1

48
SOURCES/0004-os-Account-for-bytes-to-ignore-when-sharing-input-bu.patch Normal file
View File

@ -0,0 +1,48 @@
From b4f63879f2a5cf0578101591f26471238f944e9c Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 28 Apr 2025 10:46:03 +0200
Subject: [PATCH xserver 4/7] 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>
(cherry picked from commit d55c54cecb5e83eaa2d56bed5cc4461f9ba318c2)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2025>
---
os/io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/os/io.c b/os/io.c
index de5b3c921..b7f2750b5 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.49.0

49
SOURCES/0004-xkb-Prevent-overflow-in-XkbSetCompatMap.patch Normal file
View File

@ -0,0 +1,49 @@
From c7beaec76c556870e5566b84dce7099bf28f9502 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Wed, 10 Sep 2025 16:30:29 +0200
Subject: [PATCH xserver 4/4] xkb: Prevent overflow in XkbSetCompatMap()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The XkbCompatMap structure stores its "num_si" and "size_si" fields
using an unsigned short.
However, the function _XkbSetCompatMap() will store the sum of the
input data "firstSI" and "nSI" in both XkbCompatMap's "num_si" and
"size_si" without first checking if the sum overflows the maximum
unsigned short value, leading to a possible overflow.
To avoid the issue, check whether the sum does not exceed the maximum
unsigned short value, or return a "BadValue" error otherwise.
CVE-2025-62231, ZDI-CAN-27560
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: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 475d9f49acd0e55bc0b089ed77f732ad18585470)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2088>
---
xkb/xkb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xkb/xkb.c b/xkb/xkb.c
index 6c102af0a..a77fe7ff0 100644
--- a/xkb/xkb.c
+++ b/xkb/xkb.c
@@ -2990,6 +2990,8 @@ _XkbSetCompatMap(ClientPtr client, DeviceIntPtr dev,
XkbSymInterpretPtr sym;
unsigned int skipped = 0;
+ if ((unsigned) (req->firstSI + req->nSI) > USHRT_MAX)
+ return BadValue;
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,
--
2.51.1

64
SOURCES/0005-record-Check-for-overflow-in-RecordSanityCheckRegist.patch Normal file
View File

@ -0,0 +1,64 @@
From d943eaa6b8584e7ceebd73ee59bd84e99b09be5d Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 28 Apr 2025 11:47:15 +0200
Subject: [PATCH xserver 5/7] 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/2025>
---
record/record.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/record/record.c b/record/record.c
index a8aec23bd..afaceb55c 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.49.0

43
SOURCES/0006-randr-Check-for-overflow-in-RRChangeProviderProperty.patch Normal file
View File

@ -0,0 +1,43 @@
From 3d44c08d94e850769d7d16fce0596536370253b1 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Tue, 20 May 2025 15:18:19 +0200
Subject: [PATCH xserver 6/7] 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>
(cherry picked from commit 3c3a4b767b16174d3213055947ea7f4f88e10ec6)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2025>
---
randr/rrproviderproperty.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/randr/rrproviderproperty.c b/randr/rrproviderproperty.c
index b79c17f9b..7088570ee 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.49.0

50
SOURCES/0007-xfree86-Check-for-RandR-provider-functions.patch Normal file
View File

@ -0,0 +1,50 @@
From 8de5a9b2be31d14dcce3795f919b353d62e56897 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 28 Apr 2025 14:59:46 +0200
Subject: [PATCH xserver 7/7] xfree86: Check for RandR provider functions
Changing XRandR provider properties if the driver has set no provider
function such as the modesetting driver will cause a NULL pointer
dereference and a crash of the Xorg server.
Related to 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>
(cherry picked from commit 0235121c6a7a6eb247e2addb3b41ed6ef566853d)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2025>
---
hw/xfree86/modes/xf86RandR12.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
index f220ef192..ccb7f629c 100644
--- a/hw/xfree86/modes/xf86RandR12.c
+++ b/hw/xfree86/modes/xf86RandR12.c
@@ -2133,7 +2133,8 @@ xf86RandR14ProviderSetProperty(ScreenPtr pScreen,
/* If we don't have any property handler, then we don't care what the
* user is setting properties to.
*/
- if (config->provider_funcs->set_property == NULL)
+ if (config->provider_funcs == NULL ||
+ config->provider_funcs->set_property == NULL)
return TRUE;
/*
@@ -2151,7 +2152,8 @@ xf86RandR14ProviderGetProperty(ScreenPtr pScreen,
ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(pScrn);
- if (config->provider_funcs->get_property == NULL)
+ if (config->provider_funcs == NULL ||
+ config->provider_funcs->get_property == NULL)
return TRUE;
/* Should be safe even w/o vtSema */
--
2.49.0

47
SPECS/xorg-x11-server.spec
View File

@ -42,7 +42,7 @@
Summary: X.Org X11 X server
Name: xorg-x11-server
Version: 1.20.11
Release: 28%{?gitdate:.%{gitdate}}%{?dist}
Release: 33%{?gitdate:.%{gitdate}}%{?dist}
URL: http://www.x.org
License: MIT
@ -121,6 +121,11 @@ Patch112: 0001-present-Check-for-NULL-to-prevent-crash.patch
Patch113: 0001-modesetting-Fix-msSharePixmapBacking-Segfault-Regres.patch
Patch114: 0001-present-Send-a-PresentConfigureNotify-event-for-dest.patch
Patch115: 0001-xquartz-Remove-invalid-Unicode-sequence.patch
# https://issues.redhat.com/browse/RHEL-82085
# https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1070
Patch116: 0001-dix-Force-update-LEDs-after-device-state-update-in-E.patch
# https://issues.redhat.com/browse/RHEL-84253
Patch117: 0001-xfree86-Fix-potentially-NULL-reference-to-platform-d.patch
# CVE-2021-4011
Patch10009: 0001-record-Fix-out-of-bounds-access-in-SwapCreateRegiste.patch
@ -221,6 +226,25 @@ Patch10060: 0010-sync-Do-not-let-sync-objects-uninitialized.patch
Patch10061: 0011-sync-Check-values-before-applying-changes.patch
Patch10062: 0012-sync-Do-not-fail-SyncAddTriggerToSyncObject.patch
Patch10063: 0013-sync-Apply-changes-last-in-SyncChangeAlarmAttributes.patch
# CVE-2025-49175: Out-of-bounds access in X Rendering extension
Patch10064: 0001-render-Avoid-0-or-less-animated-cursors.patch
# CVE-2025-49176: Integer overflow in Big Requests Extension
Patch10065: 0002-os-Do-not-overflow-the-integer-size-with-BigRequest.patch
Patch10066: 0003-os-Check-for-integer-overflow-on-BigRequest-length.patch
# CVE-2025-49178: Unprocessed client request via bytes to ignore
Patch10067: 0004-os-Account-for-bytes-to-ignore-when-sharing-input-bu.patch
# CVE-2025-49179: Integer overflow in X Record extension
Patch10068: 0005-record-Check-for-overflow-in-RecordSanityCheckRegist.patch
# CVE-2025-49180: Integer overflow in RandR extension
Patch10069: 0006-randr-Check-for-overflow-in-RRChangeProviderProperty.patch
Patch10070: 0007-xfree86-Check-for-RandR-provider-functions.patch
# CVE-2025-62229: Use-after-free in XPresentNotify structures creation
Patch10071: 0001-present-Fix-use-after-free-in-present_create_notifie.patch
# CVE-2025-62230: Use-after-free in Xkb client resource removal
Patch10072: 0002-xkb-Make-the-RT_XKBCLIENT-resource-private.patch
Patch10073: 0003-xkb-Free-the-XKB-resource-when-freeing-XkbInterest.patch
# CVE-2025-62231: Value overflow in Xkb extension XkbSetCompatMap()
Patch10074: 0004-xkb-Prevent-overflow-in-XkbSetCompatMap.patch
BuildRequires: make
BuildRequires: systemtap-sdt-devel
@ -631,6 +655,27 @@ find %{inst_srcdir}/hw/xfree86 -name \*.c -delete
%changelog
* Wed Jan 14 2026 Michel Dänzer <mdaenzer@redhat.com> - 1.20.11-33
- Rebuild against xorg-x11-xtrans-devel 1.4.0-9
Resolves: RHEL-117509
* Thu Oct 30 2025 Olivier Fourdan <ofourdan@redhat.com> - 1.20.11-32
- CVE fix for: CVE-2025-62229 (RHEL-119963), CVE-2025-62230 (RHEL-120035),
CVE-2025-62231 (RHEL-125003)
* Wed Jun 18 2025 Olivier Fourdan <ofourdan@redhat.com> - 1.20.11-31
- CVE fix for: CVE-2025-49175 (RHEL-97285), CVE-2025-49176 (RHEL-97308),
CVE-2025-49178 (RHEL-97387), CVE-2025-49179 (RHEL-97409),
CVE-2025-49180 (RHEL-97253)
* Tue Apr 22 2025 Michel Dänzer <mdaenzer@redhat.com> - 1.20.11-30
- xfree86: Fix potentially NULL reference to platform device's PCI device
Resolves: https://issues.redhat.com/browse/RHEL-84253
* Fri Mar 21 2025 Olivier Fourdan <ofourdan@redhat.com> - 1.20.11-29
- Fix LEDs state after suspend/resume
Resolves: https://issues.redhat.com/browse/RHEL-82085
* Wed Feb 26 2025 Olivier Fourdan <ofourdan@redhat.com> - 1.20.11-28
- CVE fix for: CVE-2025-26594 (RHEL-80201), CVE-2025-26595 (RHEL-80186),
CVE-2025-26596 (RHEL-80188), CVE-2025-26597 (RHEL-80191),