Script 'mail_helper' called by obssrc
Hello community,
here is the log from the commit of package xorg-x11-server for openSUSE:Factory
checked in at 2025-06-18 19:30:29
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/xorg-x11-server (Old)
and /work/SRC/openSUSE:Factory/.xorg-x11-server.new.19631 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "xorg-x11-server"
Wed Jun 18 19:30:29 2025 rev:442 rq:1286394 version:21.1.15
Changes:
--------
--- /work/SRC/openSUSE:Factory/xorg-x11-server/xorg-x11-server.changes
2025-04-08 17:50:00.827434226 +0200
+++
/work/SRC/openSUSE:Factory/.xorg-x11-server.new.19631/xorg-x11-server.changes
2025-06-18 19:30:34.555132563 +0200
@@ -1,0 +2,23 @@
+Fri Jun 6 10:44:07 UTC 2025 - Stefan Dirsch <sndir...@suse.com>
+
+- U_CVE-2025-49175-render-Avoid-0-or-less-animated-cursors.patch
+ * Out-of-bounds access in X Rendering extension (Animated cursors)
+ (CVE-2025-49175, bsc#1244082)
+- U_CVE-2025-49176-os-Do-not-overflow-the-integer-size-with-BigRequest.patch
+ * Integer overflow in Big Requests Extension
+ (CVE-2025-49176, bsc#1244084)
+- U_CVE-2025-49177-xfixes-Check-request-length-for-SetClientDisconnectM.patch
+ * Data leak in XFIXES Extension 6 (XFixesSetClientDisconnectMode)
+ (CVE-2025-49177, bsc#1244085)
+- U_CVE-2025-49178-os-Account-for-bytes-to-ignore-when-sharing-input-bu.patch
+ * Unprocessed client request via bytes to ignore
+ (CVE-2025-49178, bsc#1244087)
+- U_CVE-2025-49179-record-Check-for-overflow-in-RecordSanityCheckRegist.patch
+ * Integer overflow in X Record extension
+ (CVE-2025-49179, bsc#1244089)
+- U_CVE-2025-49180-randr-Check-for-overflow-in-RRChangeProviderProperty.patch
+ U_CVE-2025-49180-xfree86-Check-for-RandR-provider-functions.patch
+ * Integer overflow in RandR extension (RRChangeProviderProperty)
+ (CVE-2025-49180, bsc#1244090)
+
+-------------------------------------------------------------------
New:
----
U_CVE-2025-49175-render-Avoid-0-or-less-animated-cursors.patch
U_CVE-2025-49176-os-Do-not-overflow-the-integer-size-with-BigRequest.patch
U_CVE-2025-49177-xfixes-Check-request-length-for-SetClientDisconnectM.patch
U_CVE-2025-49178-os-Account-for-bytes-to-ignore-when-sharing-input-bu.patch
U_CVE-2025-49179-record-Check-for-overflow-in-RecordSanityCheckRegist.patch
U_CVE-2025-49180-randr-Check-for-overflow-in-RRChangeProviderProperty.patch
U_CVE-2025-49180-xfree86-Check-for-RandR-provider-functions.patch
----------(New B)----------
New:
- U_CVE-2025-49175-render-Avoid-0-or-less-animated-cursors.patch
* Out-of-bounds access in X Rendering extension (Animated cursors)
New: (CVE-2025-49175, bsc#1244082)
- U_CVE-2025-49176-os-Do-not-overflow-the-integer-size-with-BigRequest.patch
* Integer overflow in Big Requests Extension
New: (CVE-2025-49176, bsc#1244084)
- U_CVE-2025-49177-xfixes-Check-request-length-for-SetClientDisconnectM.patch
* Data leak in XFIXES Extension 6 (XFixesSetClientDisconnectMode)
New: (CVE-2025-49177, bsc#1244085)
- U_CVE-2025-49178-os-Account-for-bytes-to-ignore-when-sharing-input-bu.patch
* Unprocessed client request via bytes to ignore
New: (CVE-2025-49178, bsc#1244087)
- U_CVE-2025-49179-record-Check-for-overflow-in-RecordSanityCheckRegist.patch
* Integer overflow in X Record extension
New: (CVE-2025-49179, bsc#1244089)
- U_CVE-2025-49180-randr-Check-for-overflow-in-RRChangeProviderProperty.patch
U_CVE-2025-49180-xfree86-Check-for-RandR-provider-functions.patch
New:-
U_CVE-2025-49180-randr-Check-for-overflow-in-RRChangeProviderProperty.patch
U_CVE-2025-49180-xfree86-Check-for-RandR-provider-functions.patch
* Integer overflow in RandR extension (RRChangeProviderProperty)
----------(New E)----------
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ xorg-x11-server.spec ++++++
--- /var/tmp/diff_new_pack.LBMZMD/_old 2025-06-18 19:30:39.459330417 +0200
+++ /var/tmp/diff_new_pack.LBMZMD/_new 2025-06-18 19:30:39.483331385 +0200
@@ -259,6 +259,13 @@
Patch1237462:
U_CVE-2025-26601-0003-sync-Do-not-fail-SyncAddTriggerToSyncObject.patch
Patch1237463:
U_CVE-2025-26601-0004-sync-Apply-changes-last-in-SyncChangeAlarmAttributes.patch
Patch1239750: U_CVE-2022-49737-dix-Hold-input-lock-for-AttachDevice.patch
+Patch1244082: U_CVE-2025-49175-render-Avoid-0-or-less-animated-cursors.patch
+Patch1244084:
U_CVE-2025-49176-os-Do-not-overflow-the-integer-size-with-BigRequest.patch
+Patch1244085:
U_CVE-2025-49177-xfixes-Check-request-length-for-SetClientDisconnectM.patch
+Patch1244087:
U_CVE-2025-49178-os-Account-for-bytes-to-ignore-when-sharing-input-bu.patch
+Patch1244089:
U_CVE-2025-49179-record-Check-for-overflow-in-RecordSanityCheckRegist.patch
+Patch1244090:
U_CVE-2025-49180-randr-Check-for-overflow-in-RRChangeProviderProperty.patch
+Patch1244091:
U_CVE-2025-49180-xfree86-Check-for-RandR-provider-functions.patch
%description
This package contains the X.Org Server.
@@ -430,6 +437,14 @@
%patch -P 1239750 -p1
+%patch -P 1244082 -p1
+%patch -P 1244084 -p1
+%patch -P 1244085 -p1
+%patch -P 1244087 -p1
+%patch -P 1244089 -p1
+%patch -P 1244090 -p1
+%patch -P 1244091 -p1
+
%build
# We have some -z now related errors during X default startup (boo#1197994):
# - when loading modesetting: gbm_bo_get_plane_count
++++++ U_CVE-2025-49175-render-Avoid-0-or-less-animated-cursors.patch ++++++
>From 8c5f521c0492941794301afe107a2ee5030128af Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofour...@redhat.com>
Date: Fri, 28 Mar 2025 09:43:52 +0100
Subject: [PATCH xserver] 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 <nemmer...@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofour...@redhat.com>
Reviewed-by: José Expósito <jexpo...@redhat.com>
---
render/animcur.c | 3 +++
render/render.c | 2 ++
2 files changed, 5 insertions(+)
Index: xorg-server-21.1.15/render/animcur.c
===================================================================
--- xorg-server-21.1.15.orig/render/animcur.c
+++ xorg-server-21.1.15/render/animcur.c
@@ -304,6 +304,9 @@ AnimCursorCreate(CursorPtr *cursors, CAR
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;
Index: xorg-server-21.1.15/render/render.c
===================================================================
--- xorg-server-21.1.15.orig/render/render.c
+++ xorg-server-21.1.15/render/render.c
@@ -1795,6 +1795,8 @@ ProcRenderCreateAnimCursor(ClientPtr cli
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;
++++++
U_CVE-2025-49176-os-Do-not-overflow-the-integer-size-with-BigRequest.patch
++++++
>From d725dfd9455ab1e5393ec46f1cd725e3a784b9cc Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofour...@redhat.com>
Date: Mon, 7 Apr 2025 16:13:34 +0200
Subject: [PATCH xserver] 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 request 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 <nemmer...@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofour...@redhat.com>
Reviewed-by: Michel Dänzer <mdaen...@redhat.com>
---
dix/dispatch.c | 9 +++++----
os/io.c | 4 ++++
2 files changed, 9 insertions(+), 4 deletions(-)
Index: xorg-server-21.1.15/dix/dispatch.c
===================================================================
--- xorg-server-21.1.15.orig/dix/dispatch.c
+++ xorg-server-21.1.15/dix/dispatch.c
@@ -518,9 +518,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;
}
@@ -541,7 +542,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);
Index: xorg-server-21.1.15/os/io.c
===================================================================
--- xorg-server-21.1.15.orig/os/io.c
+++ xorg-server-21.1.15/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) {
++++++
U_CVE-2025-49177-xfixes-Check-request-length-for-SetClientDisconnectM.patch
++++++
>From eb1c0386535c5a6451cbf21ca351087ebfafb025 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofour...@redhat.com>
Date: Mon, 28 Apr 2025 10:05:36 +0200
Subject: [PATCH xserver] 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 <nemmer...@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Fixes: e167299f6 - xfixes: Add ClientDisconnectMode
Signed-off-by: Olivier Fourdan <ofour...@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
---
xfixes/disconnect.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: xorg-server-21.1.15/xfixes/disconnect.c
===================================================================
--- xorg-server-21.1.15.orig/xfixes/disconnect.c
+++ xorg-server-21.1.15/xfixes/disconnect.c
@@ -67,6 +67,7 @@ ProcXFixesSetClientDisconnectMode(Client
ClientDisconnectPtr pDisconnect = GetClientDisconnect(client);
REQUEST(xXFixesSetClientDisconnectModeReq);
+ REQUEST_SIZE_MATCH(xXFixesSetClientDisconnectModeReq);
pDisconnect->disconnect_mode = stuff->disconnect_mode;
@@ -80,7 +81,7 @@ SProcXFixesSetClientDisconnectMode(Clien
swaps(&stuff->length);
- REQUEST_AT_LEAST_SIZE(xXFixesSetClientDisconnectModeReq);
+ REQUEST_SIZE_MATCH(xXFixesSetClientDisconnectModeReq);
swapl(&stuff->disconnect_mode);
++++++
U_CVE-2025-49178-os-Account-for-bytes-to-ignore-when-sharing-input-bu.patch
++++++
>From 247f1622fa8d48783b4ed5d5154791c171f00e18 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofour...@redhat.com>
Date: Mon, 28 Apr 2025 10:46:03 +0200
Subject: [PATCH xserver] 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 <nemmer...@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofour...@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
---
os/io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/os/io.c b/os/io.c
index 0a26c988e..31c85cf34 100644
--- a/os/io.c
+++ b/os/io.c
@@ -442,7 +442,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
++++++
U_CVE-2025-49179-record-Check-for-overflow-in-RecordSanityCheckRegist.patch
++++++
>From 244101ac9d4c6963416cfc74f2174d440f1cb4b6 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofour...@redhat.com>
Date: Mon, 28 Apr 2025 11:47:15 +0200
Subject: [PATCH xserver] 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 <nemmer...@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofour...@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
---
record/record.c | 8 ++++++++
1 file changed, 8 insertions(+)
Index: xorg-server-21.1.15/record/record.c
===================================================================
--- xorg-server-21.1.15.orig/record/record.c
+++ xorg-server-21.1.15/record/record.c
@@ -36,6 +36,9 @@ and Jim Haggerty of Metheus.
#include <dix-config.h>
#endif
+#include <X11/Xdefs.h>
+#include "os/osdep.h"
+
#include "dixstruct.h"
#include "extnsionst.h"
#include "extinit.h"
@@ -1298,6 +1301,13 @@ RecordSanityCheckRegisterClients(RecordC
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;
Index: xorg-server-21.1.15/record/Makefile.am
===================================================================
--- xorg-server-21.1.15.orig/record/Makefile.am
+++ xorg-server-21.1.15/record/Makefile.am
@@ -1,6 +1,6 @@
noinst_LTLIBRARIES = librecord.la
-AM_CFLAGS = $(DIX_CFLAGS)
+AM_CFLAGS = $(DIX_CFLAGS) -I..
librecord_la_SOURCES = record.c set.c
++++++
U_CVE-2025-49180-randr-Check-for-overflow-in-RRChangeProviderProperty.patch
++++++
>From ca652633c02ceb054143207d71d24a8123733c27 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofour...@redhat.com>
Date: Tue, 20 May 2025 15:18:19 +0200
Subject: [PATCH xserver 1/2] 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 <nemmer...@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofour...@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
---
randr/rrproviderproperty.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: xorg-server-21.1.15/randr/rrproviderproperty.c
===================================================================
--- xorg-server-21.1.15.orig/randr/rrproviderproperty.c
+++ xorg-server-21.1.15/randr/rrproviderproperty.c
@@ -179,7 +179,8 @@ RRChangeProviderProperty(RRProviderPtr p
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) {
++++++ U_CVE-2025-49180-xfree86-Check-for-RandR-provider-functions.patch ++++++
>From b6f38b47c3bb31a6e7af4aeae33434ab40a969b3 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofour...@redhat.com>
Date: Mon, 28 Apr 2025 14:59:46 +0200
Subject: [PATCH xserver 2/2] 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 <nemmer...@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofour...@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
---
hw/xfree86/modes/xf86RandR12.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
Index: xorg-server-21.1.15/hw/xfree86/modes/xf86RandR12.c
===================================================================
--- xorg-server-21.1.15.orig/hw/xfree86/modes/xf86RandR12.c
+++ xorg-server-21.1.15/hw/xfree86/modes/xf86RandR12.c
@@ -2145,7 +2145,8 @@ xf86RandR14ProviderSetProperty(ScreenPtr
/* 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;
/*
@@ -2163,7 +2164,8 @@ xf86RandR14ProviderGetProperty(ScreenPtr
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 */
