rpms
/
xorg-x11-server-Xwayland
20
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

import xorg-x11-server-Xwayland-22.1.9-2.el9

Browse Source
c9 imports/c9/xorg-x11-server-Xwayland-22.1.9-2.el9
MSVSphere Packaging Team 1 year ago
parent e1e75e9be8
commit a47c63960f
25 changed files with 15 additions and 1458 deletions
Show Stats Download Patch File Download Diff File

2
.gitignore vendored
Unescape View File

@ -1 +1 @@
SOURCES/xwayland-21.1.3.tar.xz
SOURCES/xwayland-22.1.9.tar.xz

2
.xorg-x11-server-Xwayland.metadata
Unescape View File

@ -1 +1 @@
ae980a7deeb7cad9f3cd253f3b1ddca5bb26aafa SOURCES/xwayland-21.1.3.tar.xz
19ccc8ae5920620db725a08ee65d8b64c521d766 SOURCES/xwayland-22.1.9.tar.xz

36
SOURCES/0001-Xi-fix-potential-use-after-free-in-DeepCopyPointerCl.patch
Unescape View File

@ -1,36 +0,0 @@
From 8660dd164882ce5fc1f274427e2ff3dc020d6273 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Wed, 25 Jan 2023 11:41:40 +1000
Subject: [PATCH xserver] Xi: fix potential use-after-free in
DeepCopyPointerClasses
CVE-2023-0494, ZDI-CAN-19596
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 0ba6d8c37071131a49790243cdac55392ecf71ec)
---
Xi/exevents.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Xi/exevents.c b/Xi/exevents.c
index 217baa956..dcd4efb3b 100644
--- a/Xi/exevents.c
+++ b/Xi/exevents.c
@@ -619,8 +619,10 @@ DeepCopyPointerClasses(DeviceIntPtr from, DeviceIntPtr to)
memcpy(to->button->xkb_acts, from->button->xkb_acts,
sizeof(XkbAction));
}
- else
+ else {
free(to->button->xkb_acts);
+ to->button->xkb_acts = NULL;
+ }
memcpy(to->button->labels, from->button->labels,
from->button->numButtons * sizeof(Atom));
--
2.39.1

52
SOURCES/0001-Xtest-disallow-GenericEvents-in-XTestSwapFakeInput.patch
Unescape View File

@ -1,52 +0,0 @@
From 8dba686dc277d6d262ad0c77b4632a5b276697ba Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue, 29 Nov 2022 12:55:45 +1000
Subject: [PATCH xserver 1/7] Xtest: disallow GenericEvents in
XTestSwapFakeInput
XTestSwapFakeInput assumes all events in this request are
sizeof(xEvent) and iterates through these in 32-byte increments.
However, a GenericEvent may be of arbitrary length longer than 32 bytes,
so any GenericEvent in this list would result in subsequent events to be
misparsed.
Additional, the swapped event is written into a stack-allocated struct
xEvent (size 32 bytes). For any GenericEvent longer than 32 bytes,
swapping the event may thus smash the stack like an avocado on toast.
Catch this case early and return BadValue for any GenericEvent.
Which is what would happen in unswapped setups anyway since XTest
doesn't support GenericEvent.
CVE-2022-46340, ZDI-CAN 19265
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
---
Xext/xtest.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Xext/xtest.c b/Xext/xtest.c
index bf27eb590b..2985a4ce6e 100644
--- a/Xext/xtest.c
+++ b/Xext/xtest.c
@@ -502,10 +502,11 @@ XTestSwapFakeInput(ClientPtr client, xReq * req)
nev = ((req->length << 2) - sizeof(xReq)) / sizeof(xEvent);
for (ev = (xEvent *) &req[1]; --nev >= 0; ev++) {
+ int evtype = ev->u.u.type & 0x177;
/* Swap event */
- proc = EventSwapVector[ev->u.u.type & 0177];
+ proc = EventSwapVector[evtype];
/* no swapping proc; invalid event type? */
- if (!proc || proc == NotImplemented) {
+ if (!proc || proc == NotImplemented || evtype == GenericEvent) {
client->errorValue = ev->u.u.type;
return BadValue;
}
--
2.38.1

35
SOURCES/0001-record-Fix-out-of-bounds-access-in-SwapCreateRegiste.patch
Unescape View File

@ -1,35 +0,0 @@
From a8644465d98beb08759546711b77bb617861c67f Mon Sep 17 00:00:00 2001
From: Povilas Kanapickas <povilas@radix.lt>
Date: Tue, 14 Dec 2021 15:00:00 +0200
Subject: [PATCH xserver 1/4] record: Fix out of bounds access in
SwapCreateRegister()
ZDI-CAN-14952, CVE-2021-4011
This vulnerability was discovered and the fix was suggested by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
(cherry picked from commit e56f61c79fc3cee26d83cda0f84ae56d5979f768)
---
record/record.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/record/record.c b/record/record.c
index be154525d..e123867a7 100644
--- a/record/record.c
+++ b/record/record.c
@@ -2516,8 +2516,8 @@ SwapCreateRegister(ClientPtr client, xRecordRegisterClientsReq * stuff)
swapl(pClientID);
}
if (stuff->nRanges >
- client->req_len - bytes_to_int32(sz_xRecordRegisterClientsReq)
- - stuff->nClients)
+ (client->req_len - bytes_to_int32(sz_xRecordRegisterClientsReq)
+ - stuff->nClients) / bytes_to_int32(sz_xRecordRange))
return BadLength;
RecordSwapRanges((xRecordRange *) pClientID, stuff->nRanges);
return Success;
--
2.33.1

59
SOURCES/0001-xkb-fix-some-possible-memleaks-in-XkbGetKbdByName.patch
Unescape View File

@ -1,59 +0,0 @@
From 18f91b950e22c2a342a4fbc55e9ddf7534a707d2 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Wed, 13 Jul 2022 11:23:09 +1000
Subject: [PATCH xserver] xkb: fix some possible memleaks in XkbGetKbdByName
GetComponentByName returns an allocated string, so let's free that if we
fail somewhere.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
---
xkb/xkb.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/xkb/xkb.c b/xkb/xkb.c
index 4692895db..b79a269e3 100644
--- a/xkb/xkb.c
+++ b/xkb/xkb.c
@@ -5935,18 +5935,32 @@ ProcXkbGetKbdByName(ClientPtr client)
xkb = dev->key->xkbInfo->desc;
status = Success;
str = (unsigned char *) &stuff[1];
- if (GetComponentSpec(&str, TRUE, &status)) /* keymap, unsupported */
- return BadMatch;
+ {
+ char *keymap = GetComponentSpec(&str, TRUE, &status); /* keymap, unsupported */
+ if (keymap) {
+ free(keymap);
+ return BadMatch;
+ }
+ }
names.keycodes = GetComponentSpec(&str, TRUE, &status);
names.types = GetComponentSpec(&str, TRUE, &status);
names.compat = GetComponentSpec(&str, TRUE, &status);
names.symbols = GetComponentSpec(&str, TRUE, &status);
names.geometry = GetComponentSpec(&str, TRUE, &status);
- if (status != Success)
+ if (status == Success) {
+ len = str - ((unsigned char *) stuff);
+ if ((XkbPaddedSize(len) / 4) != stuff->length)
+ status = BadLength;
+ }
+
+ if (status != Success) {
+ free(names.keycodes);
+ free(names.types);
+ free(names.compat);
+ free(names.symbols);
+ free(names.geometry);
return status;
- len = str - ((unsigned char *) stuff);
- if ((XkbPaddedSize(len) / 4) != stuff->length)
- return BadLength;
+ }
CHK_MASK_LEGAL(0x01, stuff->want, XkbGBN_AllComponentsMask);
CHK_MASK_LEGAL(0x02, stuff->need, XkbGBN_AllComponentsMask);
--
2.38.1

35
SOURCES/0001-xkb-proof-GetCountedString-against-request-length-at.patch
Unescape View File

@ -1,35 +0,0 @@
From 11beef0b7f1ed290348e45618e5fa0d2bffcb72e Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue, 5 Jul 2022 12:06:20 +1000
Subject: [PATCH xserver] xkb: proof GetCountedString against request length
attacks
GetCountedString did a check for the whole string to be within the
request buffer but not for the initial 2 bytes that contain the length
field. A swapped client could send a malformed request to trigger a
swaps() on those bytes, writing into random memory.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
---
xkb/xkb.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/xkb/xkb.c b/xkb/xkb.c
index f42f59ef3..1841cff26 100644
--- a/xkb/xkb.c
+++ b/xkb/xkb.c
@@ -5137,6 +5137,11 @@ _GetCountedString(char **wire_inout, ClientPtr client, char **str)
CARD16 len;
wire = *wire_inout;
+
+ if (client->req_len <
+ bytes_to_int32(wire + 2 - (char *) client->requestBuffer))
+ return BadValue;
+
len = *(CARD16 *) wire;
if (client->swapped) {
swaps(&len);
--
2.38.1

77
SOURCES/0001-xkb-switch-to-array-index-loops-to-moving-pointers.patch
Unescape View File

@ -1,77 +0,0 @@
From c9b379ec5a1a34692af06056925bd0fc5f809713 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue, 5 Jul 2022 12:40:47 +1000
Subject: [PATCH xserver 1/3] xkb: switch to array index loops to moving
pointers
Most similar loops here use a pointer that advances with each loop
iteration, let's do the same here for consistency.
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit f1070c01d616c5f21f939d5ebc533738779451ac)
---
xkb/xkb.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/xkb/xkb.c b/xkb/xkb.c
index d056c698c..684394d77 100644
--- a/xkb/xkb.c
+++ b/xkb/xkb.c
@@ -5372,16 +5372,16 @@ _CheckSetSections(XkbGeometryPtr geom,
row->left = rWire->left;
row->vertical = rWire->vertical;
kWire = (xkbKeyWireDesc *) &rWire[1];
- for (k = 0; k < rWire->nKeys; k++) {
+ for (k = 0; k < rWire->nKeys; k++, kWire++) {
XkbKeyPtr key;
key = XkbAddGeomKey(row);
if (!key)
return BadAlloc;
- memcpy(key->name.name, kWire[k].name, XkbKeyNameLength);
- key->gap = kWire[k].gap;
- key->shape_ndx = kWire[k].shapeNdx;
- key->color_ndx = kWire[k].colorNdx;
+ memcpy(key->name.name, kWire->name, XkbKeyNameLength);
+ key->gap = kWire->gap;
+ key->shape_ndx = kWire->shapeNdx;
+ key->color_ndx = kWire->colorNdx;
if (key->shape_ndx >= geom->num_shapes) {
client->errorValue = _XkbErrCode3(0x10, key->shape_ndx,
geom->num_shapes);
@@ -5393,7 +5393,7 @@ _CheckSetSections(XkbGeometryPtr geom,
return BadMatch;
}
}
- rWire = (xkbRowWireDesc *) &kWire[rWire->nKeys];
+ rWire = (xkbRowWireDesc *)kWire;
}
wire = (char *) rWire;
if (sWire->nDoodads > 0) {
@@ -5458,16 +5458,16 @@ _CheckSetShapes(XkbGeometryPtr geom,
return BadAlloc;
ol->corner_radius = olWire->cornerRadius;
ptWire = (xkbPointWireDesc *) &olWire[1];
- for (p = 0, pt = ol->points; p < olWire->nPoints; p++, pt++) {
- pt->x = ptWire[p].x;
- pt->y = ptWire[p].y;
+ for (p = 0, pt = ol->points; p < olWire->nPoints; p++, pt++, ptWire++) {
+ pt->x = ptWire->x;
+ pt->y = ptWire->y;
if (client->swapped) {
swaps(&pt->x);
swaps(&pt->y);
}
}
ol->num_points = olWire->nPoints;
- olWire = (xkbOutlineWireDesc *) (&ptWire[olWire->nPoints]);
+ olWire = (xkbOutlineWireDesc *)ptWire;
}
if (shapeWire->primaryNdx != XkbNoShape)
shape->primary = &shape->outlines[shapeWire->primaryNdx];
--
2.36.1

43
SOURCES/0001-xwayland-eglstream-Demote-EGLstream-device-warning.patch
Unescape View File

@ -1,43 +0,0 @@
From 0a7ed9ff7ea20f7b958a2ad9f9bd045080a3ad9a Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 15 Nov 2021 16:02:34 +0100
Subject: [PATCH xserver 1/4] xwayland/eglstream: Demote EGLstream device
warning
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
If no EGLstream capable device is found at startup, Xwayland's EGLstream
backend will log an error message "glamor: No eglstream capable devices
found".
However, considering that the vast majority of drivers do not implement
EGLstream, the lack of EGLstream capable device is more of the norm than
the exception.
Change the error message to a log verbose message.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
(cherry picked from commit 96c82befa2c3f3dc3534743c67cc003c2106e9b0)
---
hw/xwayland/xwayland-glamor-eglstream.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/xwayland/xwayland-glamor-eglstream.c b/hw/xwayland/xwayland-glamor-eglstream.c
index 8d18caaf5..93d192d58 100644
--- a/hw/xwayland/xwayland-glamor-eglstream.c
+++ b/hw/xwayland/xwayland-glamor-eglstream.c
@@ -1144,7 +1144,7 @@ xwl_eglstream_get_device(struct xwl_screen *xwl_screen)
free(devices);
out:
if (!device)
- ErrorF("glamor: No eglstream capable devices found\n");
+ LogMessageVerb(X_INFO, 3, "glamor: No eglstream capable devices found\n");
return device;
}
--
2.33.1

41
SOURCES/0002-Xi-return-an-error-from-XI-property-changes-if-verif.patch
Unescape View File

@ -1,41 +0,0 @@
From c5ff57676698f19ed3a1402aef58a15552e32d27 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue, 29 Nov 2022 13:24:00 +1000
Subject: [PATCH xserver 2/7] Xi: return an error from XI property changes if
verification failed
Both ProcXChangeDeviceProperty and ProcXIChangeProperty checked the
property for validity but didn't actually return the potential error.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
---
Xi/xiproperty.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
index a36f7d61df..68c362c628 100644
--- a/Xi/xiproperty.c
+++ b/Xi/xiproperty.c
@@ -902,6 +902,8 @@ ProcXChangeDeviceProperty(ClientPtr client)
rc = check_change_property(client, stuff->property, stuff->type,
stuff->format, stuff->mode, stuff->nUnits);
+ if (rc != Success)
+ return rc;
len = stuff->nUnits;
if (len > (bytes_to_int32(0xffffffff - sizeof(xChangeDevicePropertyReq))))
@@ -1141,6 +1143,9 @@ ProcXIChangeProperty(ClientPtr client)
rc = check_change_property(client, stuff->property, stuff->type,
stuff->format, stuff->mode, stuff->num_items);
+ if (rc != Success)
+ return rc;
+
len = stuff->num_items;
if (len > bytes_to_int32(0xffffffff - sizeof(xXIChangePropertyReq)))
return BadLength;
--
2.38.1

44
SOURCES/0002-xfixes-Fix-out-of-bounds-access-in-ProcXFixesCreateP.patch
Unescape View File

@ -1,44 +0,0 @@
From 3eb5445f6f7fa9f86de87adc768105d42bdbcf74 Mon Sep 17 00:00:00 2001
From: Povilas Kanapickas <povilas@radix.lt>
Date: Tue, 14 Dec 2021 15:00:01 +0200
Subject: [PATCH xserver 2/4] xfixes: Fix out of bounds access in
*ProcXFixesCreatePointerBarrier()
ZDI-CAN-14950, CVE-2021-4009
This vulnerability was discovered and the fix was suggested by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
(cherry picked from commit b5196750099ae6ae582e1f46bd0a6dad29550e02)
---
xfixes/cursor.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xfixes/cursor.c b/xfixes/cursor.c
index 60580b88f..c5d4554b2 100644
--- a/xfixes/cursor.c
+++ b/xfixes/cursor.c
@@ -1010,7 +1010,8 @@ ProcXFixesCreatePointerBarrier(ClientPtr client)
{
REQUEST(xXFixesCreatePointerBarrierReq);
- REQUEST_FIXED_SIZE(xXFixesCreatePointerBarrierReq, pad_to_int32(stuff->num_devices));
+ REQUEST_FIXED_SIZE(xXFixesCreatePointerBarrierReq,
+ pad_to_int32(stuff->num_devices * sizeof(CARD16)));
LEGAL_NEW_RESOURCE(stuff->barrier, client);
return XICreatePointerBarrier(client, stuff);
@@ -1027,7 +1028,8 @@ SProcXFixesCreatePointerBarrier(ClientPtr client)
swaps(&stuff->length);
swaps(&stuff->num_devices);
- REQUEST_FIXED_SIZE(xXFixesCreatePointerBarrierReq, pad_to_int32(stuff->num_devices));
+ REQUEST_FIXED_SIZE(xXFixesCreatePointerBarrierReq,
+ pad_to_int32(stuff->num_devices * sizeof(CARD16)));
swapl(&stuff->barrier);
swapl(&stuff->window);
--
2.33.1

180
SOURCES/0002-xkb-swap-XkbSetDeviceInfo-and-XkbSetDeviceInfoCheck.patch
Unescape View File

@ -1,180 +0,0 @@
From 45a0af83129eb7dc244c5118360afc1972a686c7 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue, 5 Jul 2022 09:50:41 +1000
Subject: [PATCH xserver 2/3] xkb: swap XkbSetDeviceInfo and
XkbSetDeviceInfoCheck
XKB often uses a FooCheck and Foo function pair, the former is supposed
to check all values in the request and error out on BadLength,
BadValue, etc. The latter is then called once we're confident the values
are good (they may still fail on an individual device, but that's a
different topic).
In the case of XkbSetDeviceInfo, those functions were incorrectly
named, with XkbSetDeviceInfo ending up as the checker function and
XkbSetDeviceInfoCheck as the setter function. As a result, the setter
function was called before the checker function, accessing request
data and modifying device state before we ensured that the data is
valid.
In particular, the setter function relied on values being already
byte-swapped. This in turn could lead to potential OOB memory access.
Fix this by correctly naming the functions and moving the length checks
over to the checker function. These were added in 87c64fc5b0 to the
wrong function, probably due to the incorrect naming.
Fixes ZDI-CAN 16070, CVE-2022-2320.
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Introduced in c06e27b2f6fd9f7b9f827623a48876a225264132
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit dd8caf39e9e15d8f302e54045dd08d8ebf1025dc)
---
xkb/xkb.c | 46 +++++++++++++++++++++++++---------------------
1 file changed, 25 insertions(+), 21 deletions(-)
diff --git a/xkb/xkb.c b/xkb/xkb.c
index 684394d77..36464a770 100644
--- a/xkb/xkb.c
+++ b/xkb/xkb.c
@@ -6554,7 +6554,8 @@ ProcXkbGetDeviceInfo(ClientPtr client)
static char *
CheckSetDeviceIndicators(char *wire,
DeviceIntPtr dev,
- int num, int *status_rtrn, ClientPtr client)
+ int num, int *status_rtrn, ClientPtr client,
+ xkbSetDeviceInfoReq * stuff)
{
xkbDeviceLedsWireDesc *ledWire;
int i;
@@ -6562,6 +6563,11 @@ CheckSetDeviceIndicators(char *wire,
ledWire = (xkbDeviceLedsWireDesc *) wire;
for (i = 0; i < num; i++) {
+ if (!_XkbCheckRequestBounds(client, stuff, ledWire, ledWire + 1)) {
+ *status_rtrn = BadLength;
+ return (char *) ledWire;
+ }
+
if (client->swapped) {
swaps(&ledWire->ledClass);
swaps(&ledWire->ledID);
@@ -6589,6 +6595,11 @@ CheckSetDeviceIndicators(char *wire,
atomWire = (CARD32 *) &ledWire[1];
if (nNames > 0) {
for (n = 0; n < nNames; n++) {
+ if (!_XkbCheckRequestBounds(client, stuff, atomWire, atomWire + 1)) {
+ *status_rtrn = BadLength;
+ return (char *) atomWire;
+ }
+
if (client->swapped) {
swapl(atomWire);
}
@@ -6600,6 +6611,10 @@ CheckSetDeviceIndicators(char *wire,
mapWire = (xkbIndicatorMapWireDesc *) atomWire;
if (nMaps > 0) {
for (n = 0; n < nMaps; n++) {
+ if (!_XkbCheckRequestBounds(client, stuff, mapWire, mapWire + 1)) {
+ *status_rtrn = BadLength;
+ return (char *) mapWire;
+ }
if (client->swapped) {
swaps(&mapWire->virtualMods);
swapl(&mapWire->ctrls);
@@ -6651,11 +6666,6 @@ SetDeviceIndicators(char *wire,
xkbIndicatorMapWireDesc *mapWire;
XkbSrvLedInfoPtr sli;
- if (!_XkbCheckRequestBounds(client, stuff, ledWire, ledWire + 1)) {
- *status_rtrn = BadLength;
- return (char *) ledWire;
- }
-
namec = mapc = statec = 0;
sli = XkbFindSrvLedInfo(dev, ledWire->ledClass, ledWire->ledID,
XkbXI_IndicatorMapsMask);
@@ -6674,10 +6684,6 @@ SetDeviceIndicators(char *wire,
memset((char *) sli->names, 0, XkbNumIndicators * sizeof(Atom));
for (n = 0, bit = 1; n < XkbNumIndicators; n++, bit <<= 1) {
if (ledWire->namesPresent & bit) {
- if (!_XkbCheckRequestBounds(client, stuff, atomWire, atomWire + 1)) {
- *status_rtrn = BadLength;
- return (char *) atomWire;
- }
sli->names[n] = (Atom) *atomWire;
if (sli->names[n] == None)
ledWire->namesPresent &= ~bit;
@@ -6695,10 +6701,6 @@ SetDeviceIndicators(char *wire,
if (ledWire->mapsPresent) {
for (n = 0, bit = 1; n < XkbNumIndicators; n++, bit <<= 1) {
if (ledWire->mapsPresent & bit) {
- if (!_XkbCheckRequestBounds(client, stuff, mapWire, mapWire + 1)) {
- *status_rtrn = BadLength;
- return (char *) mapWire;
- }
sli->maps[n].flags = mapWire->flags;
sli->maps[n].which_groups = mapWire->whichGroups;
sli->maps[n].groups = mapWire->groups;
@@ -6734,13 +6736,17 @@ SetDeviceIndicators(char *wire,
}
static int
-_XkbSetDeviceInfo(ClientPtr client, DeviceIntPtr dev,
+_XkbSetDeviceInfoCheck(ClientPtr client, DeviceIntPtr dev,
xkbSetDeviceInfoReq * stuff)
{
char *wire;
wire = (char *) &stuff[1];
if (stuff->change & XkbXI_ButtonActionsMask) {
+ int sz = stuff->nBtns * SIZEOF(xkbActionWireDesc);
+ if (!_XkbCheckRequestBounds(client, stuff, wire, (char *) wire + sz))
+ return BadLength;
+
if (!dev->button) {
client->errorValue = _XkbErrCode2(XkbErr_BadClass, ButtonClass);
return XkbKeyboardErrorCode;
@@ -6751,13 +6757,13 @@ _XkbSetDeviceInfo(ClientPtr client, DeviceIntPtr dev,
dev->button->numButtons);
return BadMatch;
}
- wire += (stuff->nBtns * SIZEOF(xkbActionWireDesc));
+ wire += sz;
}
if (stuff->change & XkbXI_IndicatorsMask) {
int status = Success;
wire = CheckSetDeviceIndicators(wire, dev, stuff->nDeviceLedFBs,
- &status, client);
+ &status, client, stuff);
if (status != Success)
return status;
}
@@ -6768,8 +6774,8 @@ _XkbSetDeviceInfo(ClientPtr client, DeviceIntPtr dev,
}
static int
-_XkbSetDeviceInfoCheck(ClientPtr client, DeviceIntPtr dev,
- xkbSetDeviceInfoReq * stuff)
+_XkbSetDeviceInfo(ClientPtr client, DeviceIntPtr dev,
+ xkbSetDeviceInfoReq * stuff)
{
char *wire;
xkbExtensionDeviceNotify ed;
@@ -6793,8 +6799,6 @@ _XkbSetDeviceInfoCheck(ClientPtr client, DeviceIntPtr dev,
if (stuff->firstBtn + stuff->nBtns > nBtns)
return BadValue;
sz = stuff->nBtns * SIZEOF(xkbActionWireDesc);
- if (!_XkbCheckRequestBounds(client, stuff, wire, (char *) wire + sz))
- return BadLength;
memcpy((char *) &acts[stuff->firstBtn], (char *) wire, sz);
wire += sz;
ed.reason |= XkbXI_ButtonActionsMask;
--
2.36.1

88
SOURCES/0002-xwayland-glamor-Change-errors-to-verbose-messages.patch
Unescape View File

@ -1,88 +0,0 @@
From a515f4f4336efb8a2adf9a3ac141129708297d80 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 29 Nov 2021 11:45:35 +0100
Subject: [PATCH xserver 2/4] xwayland/glamor: Change errors to verbose
messages
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
On a normal startup sequence, the Xwayland glamor backend would log
an error whenever a required Wayland protocol is missing.
Those are not really errors though, more informational messages along
the glamor backend selection process.
Demote those errors to verbose messages to reduce the verbosity of
Xwayland at startup by default.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
(cherry picked from commit 30d0d4a19be61dd7b61f5ced992cb299e6a38068)
---
hw/xwayland/xwayland-glamor-eglstream.c | 6 ++++--
hw/xwayland/xwayland-glamor-gbm.c | 2 +-
hw/xwayland/xwayland-glamor.c | 6 ++++--
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/hw/xwayland/xwayland-glamor-eglstream.c b/hw/xwayland/xwayland-glamor-eglstream.c
index 93d192d58..5a20b452f 100644
--- a/hw/xwayland/xwayland-glamor-eglstream.c
+++ b/hw/xwayland/xwayland-glamor-eglstream.c
@@ -753,12 +753,14 @@ xwl_glamor_eglstream_has_wl_interfaces(struct xwl_screen *xwl_screen)
xwl_eglstream_get(xwl_screen);
if (xwl_eglstream->display == NULL) {
- ErrorF("glamor: 'wl_eglstream_display' not supported\n");
+ LogMessageVerb(X_INFO, 3,
+ "glamor: 'wl_eglstream_display' not supported\n");
return FALSE;
}
if (xwl_eglstream->controller == NULL) {
- ErrorF("glamor: 'wl_eglstream_controller' not supported\n");
+ LogMessageVerb(X_INFO, 3,
+ "glamor: 'wl_eglstream_controller' not supported\n");
return FALSE;
}
diff --git a/hw/xwayland/xwayland-glamor-gbm.c b/hw/xwayland/xwayland-glamor-gbm.c
index 466a1b052..e06b6f54b 100644
--- a/hw/xwayland/xwayland-glamor-gbm.c
+++ b/hw/xwayland/xwayland-glamor-gbm.c
@@ -835,7 +835,7 @@ xwl_glamor_gbm_has_wl_interfaces(struct xwl_screen *xwl_screen)
struct xwl_gbm_private *xwl_gbm = xwl_gbm_get(xwl_screen);
if (xwl_gbm->drm == NULL) {
- ErrorF("glamor: 'wl_drm' not supported\n");
+ LogMessageVerb(X_INFO, 3, "glamor: 'wl_drm' not supported\n");
return FALSE;
}
diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
index deb398f91..541d5e923 100644
--- a/hw/xwayland/xwayland-glamor.c
+++ b/hw/xwayland/xwayland-glamor.c
@@ -412,7 +412,8 @@ xwl_glamor_select_gbm_backend(struct xwl_screen *xwl_screen)
return TRUE;
}
else
- ErrorF("Missing Wayland requirements for glamor GBM backend\n");
+ LogMessageVerb(X_INFO, 3,
+ "Missing Wayland requirements for glamor GBM backend\n");
#endif
return FALSE;
@@ -428,7 +429,8 @@ xwl_glamor_select_eglstream_backend(struct xwl_screen *xwl_screen)
return TRUE;
}
else
- ErrorF("Missing Wayland requirements for glamor EGLStream backend\n");
+ LogMessageVerb(X_INFO, 3,
+ "Missing Wayland requirements for glamor EGLStream backend\n");
#endif
return FALSE;
--
2.33.1

34
SOURCES/0003-Xext-Fix-out-of-bounds-access-in-SProcScreenSaverSus.patch
Unescape View File

@ -1,34 +0,0 @@
From fe0c050276c09f43cc1ae80b4553db42398ca84c Mon Sep 17 00:00:00 2001
From: Povilas Kanapickas <povilas@radix.lt>
Date: Tue, 14 Dec 2021 15:00:02 +0200
Subject: [PATCH xserver 3/4] Xext: Fix out of bounds access in
SProcScreenSaverSuspend()
ZDI-CAN-14951, CVE-2021-4010
This vulnerability was discovered and the fix was suggested by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
(cherry picked from commit 6c4c53010772e3cb4cb8acd54950c8eec9c00d21)
---
Xext/saver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Xext/saver.c b/Xext/saver.c
index 1d7e3cadf..f813ba08d 100644
--- a/Xext/saver.c
+++ b/Xext/saver.c
@@ -1351,8 +1351,8 @@ SProcScreenSaverSuspend(ClientPtr client)
REQUEST(xScreenSaverSuspendReq);
swaps(&stuff->length);
- swapl(&stuff->suspend);
REQUEST_SIZE_MATCH(xScreenSaverSuspendReq);
+ swapl(&stuff->suspend);
return ProcScreenSaverSuspend(client);
}
--
2.33.1

71
SOURCES/0003-Xi-avoid-integer-truncation-in-length-check-of-ProcX.patch
Unescape View File

@ -1,71 +0,0 @@
From f9c435822c852659e3926502829f1b13ce6efc37 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue, 29 Nov 2022 13:26:57 +1000
Subject: [PATCH xserver 3/7] Xi: avoid integer truncation in length check of
ProcXIChangeProperty
This fixes an OOB read and the resulting information disclosure.
Length calculation for the request was clipped to a 32-bit integer. With
the correct stuff->num_items value the expected request size was
truncated, passing the REQUEST_FIXED_SIZE check.
The server then proceeded with reading at least stuff->num_items bytes
(depending on stuff->format) from the request and stuffing whatever it
finds into the property. In the process it would also allocate at least
stuff->num_items bytes, i.e. 4GB.
The same bug exists in ProcChangeProperty and ProcXChangeDeviceProperty,
so let's fix that too.
CVE-2022-46344, ZDI-CAN 19405
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
---
Xi/xiproperty.c | 4 ++--
dix/property.c | 3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
index 68c362c628..066ba21fba 100644
--- a/Xi/xiproperty.c
+++ b/Xi/xiproperty.c
@@ -890,7 +890,7 @@ ProcXChangeDeviceProperty(ClientPtr client)
REQUEST(xChangeDevicePropertyReq);
DeviceIntPtr dev;
unsigned long len;
- int totalSize;
+ uint64_t totalSize;
int rc;
REQUEST_AT_LEAST_SIZE(xChangeDevicePropertyReq);
@@ -1130,7 +1130,7 @@ ProcXIChangeProperty(ClientPtr client)
{
int rc;
DeviceIntPtr dev;
- int totalSize;
+ uint64_t totalSize;
unsigned long len;
REQUEST(xXIChangePropertyReq);
diff --git a/dix/property.c b/dix/property.c
index 94ef5a0ec0..acce94b2c6 100644
--- a/dix/property.c
+++ b/dix/property.c
@@ -205,7 +205,8 @@ ProcChangeProperty(ClientPtr client)
WindowPtr pWin;
char format, mode;
unsigned long len;
- int sizeInBytes, totalSize, err;
+ int sizeInBytes, err;
+ uint64_t totalSize;
REQUEST(xChangePropertyReq);
--
2.38.1

183
SOURCES/0003-xkb-add-request-length-validation-for-XkbSetGeometry.patch
Unescape View File

@ -1,183 +0,0 @@
From bd134231e282d9eb126b6fdaa40bb383180fa72b Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue, 5 Jul 2022 11:11:06 +1000
Subject: [PATCH xserver 3/3] xkb: add request length validation for
XkbSetGeometry
No validation of the various fields on that report were done, so a
malicious client could send a short request that claims it had N
sections, or rows, or keys, and the server would process the request for
N sections, running out of bounds of the actual request data.
Fix this by adding size checks to ensure our data is valid.
ZDI-CAN 16062, CVE-2022-2319.
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 6907b6ea2b4ce949cb07271f5b678d5966d9df42)
---
xkb/xkb.c | 43 ++++++++++++++++++++++++++++++++++++++-----
1 file changed, 38 insertions(+), 5 deletions(-)
diff --git a/xkb/xkb.c b/xkb/xkb.c
index 36464a770..27d19793e 100644
--- a/xkb/xkb.c
+++ b/xkb/xkb.c
@@ -5160,7 +5160,7 @@ _GetCountedString(char **wire_inout, ClientPtr client, char **str)
}
static Status
-_CheckSetDoodad(char **wire_inout,
+_CheckSetDoodad(char **wire_inout, xkbSetGeometryReq *req,
XkbGeometryPtr geom, XkbSectionPtr section, ClientPtr client)
{
char *wire;
@@ -5171,6 +5171,9 @@ _CheckSetDoodad(char **wire_inout,
Status status;
dWire = (xkbDoodadWireDesc *) (*wire_inout);
+ if (!_XkbCheckRequestBounds(client, req, dWire, dWire + 1))
+ return BadLength;
+
any = dWire->any;
wire = (char *) &dWire[1];
if (client->swapped) {
@@ -5273,7 +5276,7 @@ _CheckSetDoodad(char **wire_inout,
}
static Status
-_CheckSetOverlay(char **wire_inout,
+_CheckSetOverlay(char **wire_inout, xkbSetGeometryReq *req,
XkbGeometryPtr geom, XkbSectionPtr section, ClientPtr client)
{
register int r;
@@ -5284,6 +5287,9 @@ _CheckSetOverlay(char **wire_inout,
wire = *wire_inout;
olWire = (xkbOverlayWireDesc *) wire;
+ if (!_XkbCheckRequestBounds(client, req, olWire, olWire + 1))
+ return BadLength;
+
if (client->swapped) {
swapl(&olWire->name);
}
@@ -5295,6 +5301,9 @@ _CheckSetOverlay(char **wire_inout,
xkbOverlayKeyWireDesc *kWire;
XkbOverlayRowPtr row;
+ if (!_XkbCheckRequestBounds(client, req, rWire, rWire + 1))
+ return BadLength;
+
if (rWire->rowUnder > section->num_rows) {
client->errorValue = _XkbErrCode4(0x20, r, section->num_rows,
rWire->rowUnder);
@@ -5303,6 +5312,9 @@ _CheckSetOverlay(char **wire_inout,
row = XkbAddGeomOverlayRow(ol, rWire->rowUnder, rWire->nKeys);
kWire = (xkbOverlayKeyWireDesc *) &rWire[1];
for (k = 0; k < rWire->nKeys; k++, kWire++) {
+ if (!_XkbCheckRequestBounds(client, req, kWire, kWire + 1))
+ return BadLength;
+
if (XkbAddGeomOverlayKey(ol, row,
(char *) kWire->over,
(char *) kWire->under) == NULL) {
@@ -5336,6 +5348,9 @@ _CheckSetSections(XkbGeometryPtr geom,
register int r;
xkbRowWireDesc *rWire;
+ if (!_XkbCheckRequestBounds(client, req, sWire, sWire + 1))
+ return BadLength;
+
if (client->swapped) {
swapl(&sWire->name);
swaps(&sWire->top);
@@ -5361,6 +5376,9 @@ _CheckSetSections(XkbGeometryPtr geom,
XkbRowPtr row;
xkbKeyWireDesc *kWire;
+ if (!_XkbCheckRequestBounds(client, req, rWire, rWire + 1))
+ return BadLength;
+
if (client->swapped) {
swaps(&rWire->top);
swaps(&rWire->left);
@@ -5375,6 +5393,9 @@ _CheckSetSections(XkbGeometryPtr geom,
for (k = 0; k < rWire->nKeys; k++, kWire++) {
XkbKeyPtr key;
+ if (!_XkbCheckRequestBounds(client, req, kWire, kWire + 1))
+ return BadLength;
+
key = XkbAddGeomKey(row);
if (!key)
return BadAlloc;
@@ -5400,7 +5421,7 @@ _CheckSetSections(XkbGeometryPtr geom,
register int d;
for (d = 0; d < sWire->nDoodads; d++) {
- status = _CheckSetDoodad(&wire, geom, section, client);
+ status = _CheckSetDoodad(&wire, req, geom, section, client);
if (status != Success)
return status;
}
@@ -5409,7 +5430,7 @@ _CheckSetSections(XkbGeometryPtr geom,
register int o;
for (o = 0; o < sWire->nOverlays; o++) {
- status = _CheckSetOverlay(&wire, geom, section, client);
+ status = _CheckSetOverlay(&wire, req, geom, section, client);
if (status != Success)
return status;
}
@@ -5443,6 +5464,9 @@ _CheckSetShapes(XkbGeometryPtr geom,
xkbOutlineWireDesc *olWire;
XkbOutlinePtr ol;
+ if (!_XkbCheckRequestBounds(client, req, shapeWire, shapeWire + 1))
+ return BadLength;
+
shape =
XkbAddGeomShape(geom, shapeWire->name, shapeWire->nOutlines);
if (!shape)
@@ -5453,12 +5477,18 @@ _CheckSetShapes(XkbGeometryPtr geom,
XkbPointPtr pt;
xkbPointWireDesc *ptWire;
+ if (!_XkbCheckRequestBounds(client, req, olWire, olWire + 1))
+ return BadLength;
+
ol = XkbAddGeomOutline(shape, olWire->nPoints);
if (!ol)
return BadAlloc;
ol->corner_radius = olWire->cornerRadius;
ptWire = (xkbPointWireDesc *) &olWire[1];
for (p = 0, pt = ol->points; p < olWire->nPoints; p++, pt++, ptWire++) {
+ if (!_XkbCheckRequestBounds(client, req, ptWire, ptWire + 1))
+ return BadLength;
+
pt->x = ptWire->x;
pt->y = ptWire->y;
if (client->swapped) {
@@ -5564,12 +5594,15 @@ _CheckSetGeom(XkbGeometryPtr geom, xkbSetGeometryReq * req, ClientPtr client)
return status;
for (i = 0; i < req->nDoodads; i++) {
- status = _CheckSetDoodad(&wire, geom, NULL, client);
+ status = _CheckSetDoodad(&wire, req, geom, NULL, client);
if (status != Success)
return status;
}
for (i = 0; i < req->nKeyAliases; i++) {
+ if (!_XkbCheckRequestBounds(client, req, wire, wire + XkbKeyNameLength))
+ return BadLength;
+
if (XkbAddGeomKeyAlias(geom, &wire[XkbKeyNameLength], wire) == NULL)
return BadAlloc;
wire += 2 * XkbKeyNameLength;
--
2.36.1

42
SOURCES/0003-xwayland-glamor-Log-backend-selected-for-debug.patch
Unescape View File

@ -1,42 +0,0 @@
From 3206e133cb768709d32f260ac4b1bb17a46141a7 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Wed, 17 Nov 2021 13:09:58 +0100
Subject: [PATCH xserver 3/4] xwayland/glamor: Log backend selected for debug
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Add (verbose) statements to trace the actual backend used with glamor.
That can be useful for debugging.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit c5d1fed9fa32244739677ec5c58ea87b261e023b)
---
hw/xwayland/xwayland-glamor.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
index 541d5e923..b34eafabb 100644
--- a/hw/xwayland/xwayland-glamor.c
+++ b/hw/xwayland/xwayland-glamor.c
@@ -409,6 +409,7 @@ xwl_glamor_select_gbm_backend(struct xwl_screen *xwl_screen)
if (xwl_screen->gbm_backend.is_available &&
xwl_glamor_has_wl_interfaces(xwl_screen, &xwl_screen->gbm_backend)) {
xwl_screen->egl_backend = &xwl_screen->gbm_backend;
+ LogMessageVerb(X_INFO, 3, "glamor: Using GBM backend\n");
return TRUE;
}
else
@@ -426,6 +427,7 @@ xwl_glamor_select_eglstream_backend(struct xwl_screen *xwl_screen)
if (xwl_screen->eglstream_backend.is_available &&
xwl_glamor_has_wl_interfaces(xwl_screen, &xwl_screen->eglstream_backend)) {
xwl_screen->egl_backend = &xwl_screen->eglstream_backend;
+ LogMessageVerb(X_INFO, 3, "glamor: Using EGLStream backend\n");
return TRUE;
}
else
--
2.33.1

82
SOURCES/0004-Xi-disallow-passive-grabs-with-a-detail-255.patch
Unescape View File

@ -1,82 +0,0 @@
From 0dab0b527ac5c4fe0272ea679522bd87238a733b Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue, 29 Nov 2022 13:55:32 +1000
Subject: [PATCH xserver 4/7] Xi: disallow passive grabs with a detail > 255
The XKB protocol effectively prevents us from ever using keycodes above
255. For buttons it's theoretically possible but realistically too niche
to worry about. For all other passive grabs, the detail must be zero
anyway.
This fixes an OOB write:
ProcXIPassiveUngrabDevice() calls DeletePassiveGrabFromList with a
temporary grab struct which contains tempGrab->detail.exact = stuff->detail.
For matching existing grabs, DeleteDetailFromMask is called with the
stuff->detail value. This function creates a new mask with the one bit
representing stuff->detail cleared.
However, the array size for the new mask is 8 * sizeof(CARD32) bits,
thus any detail above 255 results in an OOB array write.
CVE-2022-46341, ZDI-CAN 19381
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
---
Xi/xipassivegrab.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/Xi/xipassivegrab.c b/Xi/xipassivegrab.c
index 2769fb7c94..c9ac2f8553 100644
--- a/Xi/xipassivegrab.c
+++ b/Xi/xipassivegrab.c
@@ -137,6 +137,12 @@ ProcXIPassiveGrabDevice(ClientPtr client)
return BadValue;
}
+ /* XI2 allows 32-bit keycodes but thanks to XKB we can never
+ * implement this. Just return an error for all keycodes that
+ * cannot work anyway, same for buttons > 255. */
+ if (stuff->detail > 255)
+ return XIAlreadyGrabbed;
+
if (XICheckInvalidMaskBits(client, (unsigned char *) &stuff[1],
stuff->mask_len * 4) != Success)
return BadValue;
@@ -207,14 +213,8 @@ ProcXIPassiveGrabDevice(ClientPtr client)
&param, XI2, &mask);
break;
case XIGrabtypeKeycode:
- /* XI2 allows 32-bit keycodes but thanks to XKB we can never
- * implement this. Just return an error for all keycodes that
- * cannot work anyway */
- if (stuff->detail > 255)
- status = XIAlreadyGrabbed;
- else
- status = GrabKey(client, dev, mod_dev, stuff->detail,
- &param, XI2, &mask);
+ status = GrabKey(client, dev, mod_dev, stuff->detail,
+ &param, XI2, &mask);
break;
case XIGrabtypeEnter:
case XIGrabtypeFocusIn:
@@ -334,6 +334,12 @@ ProcXIPassiveUngrabDevice(ClientPtr client)
return BadValue;
}
+ /* We don't allow passive grabs for details > 255 anyway */
+ if (stuff->detail > 255) {
+ client->errorValue = stuff->detail;
+ return BadValue;
+ }
+
rc = dixLookupWindow(&win, stuff->grab_window, client, DixSetAttrAccess);
if (rc != Success)
return rc;
--
2.38.1

53
SOURCES/0004-render-Fix-out-of-bounds-access-in-SProcRenderCompos.patch
Unescape View File

@ -1,53 +0,0 @@
From 59c977bff66de77bd93ce8853e33e1b4ca661a49 Mon Sep 17 00:00:00 2001
From: Povilas Kanapickas <povilas@radix.lt>
Date: Tue, 14 Dec 2021 15:00:03 +0200
Subject: [PATCH xserver 4/4] render: Fix out of bounds access in
SProcRenderCompositeGlyphs()
ZDI-CAN-14192, CVE-2021-4008
This vulnerability was discovered and the fix was suggested by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
(cherry picked from commit ebce7e2d80e7c80e1dda60f2f0bc886f1106ba60)
---
render/render.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/render/render.c b/render/render.c
index c376090ca..456f156d4 100644
--- a/render/render.c
+++ b/render/render.c
@@ -2309,6 +2309,9 @@ SProcRenderCompositeGlyphs(ClientPtr client)
i = elt->len;
if (i == 0xff) {
+ if (buffer + 4 > end) {
+ return BadLength;
+ }
swapl((int *) buffer);
buffer += 4;
}
@@ -2319,12 +2322,18 @@ SProcRenderCompositeGlyphs(ClientPtr client)
buffer += i;
break;
case 2:
+ if (buffer + i * 2 > end) {
+ return BadLength;
+ }
while (i--) {
swaps((short *) buffer);
buffer += 2;
}
break;
case 4:
+ if (buffer + i * 4 > end) {
+ return BadLength;
+ }
while (i--) {
swapl((int *) buffer);
buffer += 4;
--
2.33.1

64
SOURCES/0004-xwayland-eglstream-Prefer-EGLstream-if-available.patch
Unescape View File

@ -1,64 +0,0 @@
From bdc00ba749ac6cde35c025f5f6b1a5b49c1f4960 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Wed, 17 Nov 2021 09:56:52 +0100
Subject: [PATCH xserver 4/4] xwayland/eglstream: Prefer EGLstream if available
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Currently, when given the choice, Xwayland will pick the GBM backend
over the EGLstream backend if both are available, unless the command
line option “-eglstream” is specified.
The NVIDIA proprietary driver had no support for GBM until driver series
495, but starting with the driver series 495, both can be used.
But there are other requirements with the rest of the stack, typically
Mesa, egl-wayland, libglvnd as documented in the NVIDIA driver.
So if the NVIDIA driver series 495 gets installed, Xwayland will pick
the GBM backend even if EGLstream is available and may fail to render
properly.
To avoid that issue, prefer EGLstream if EGLstream and all the Wayland
interfaces are available, and fallback to GBM automatically unless
“-eglstream” was specified.
With this, the compositor, given the choice, can decide which actual
backend Xwayland would use by advertising (or not) the Wayland
"wl_eglstream_controller" interface.
This change has no impact on compositors which do not have support for
EGLstream in the first place.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 6dd9709bd85cf5de4067887818c864220b951355)
---
hw/xwayland/xwayland-glamor.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
index b34eafabb..f46b677f5 100644
--- a/hw/xwayland/xwayland-glamor.c
+++ b/hw/xwayland/xwayland-glamor.c
@@ -441,14 +441,10 @@ xwl_glamor_select_eglstream_backend(struct xwl_screen *xwl_screen)
void
xwl_glamor_select_backend(struct xwl_screen *xwl_screen, Bool use_eglstream)
{
- if (use_eglstream) {
- if (!xwl_glamor_select_eglstream_backend(xwl_screen))
+ if (!xwl_glamor_select_eglstream_backend(xwl_screen)) {
+ if (!use_eglstream)
xwl_glamor_select_gbm_backend(xwl_screen);
}
- else {
- if (!xwl_glamor_select_gbm_backend(xwl_screen))
- xwl_glamor_select_eglstream_backend(xwl_screen);
- }
}
Bool
--
2.33.1

48
SOURCES/0005-Xext-free-the-screen-saver-resource-when-replacing-i.patch
Unescape View File

@ -1,48 +0,0 @@
From 94f6fe99d87cf6ba0adadd95c595158c345b7d29 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue, 29 Nov 2022 14:53:07 +1000
Subject: [PATCH xserver 5/7] Xext: free the screen saver resource when
replacing it
This fixes a use-after-free bug:
When a client first calls ScreenSaverSetAttributes(), a struct
ScreenSaverAttrRec is allocated and added to the client's
resources.
When the same client calls ScreenSaverSetAttributes() again, a new
struct ScreenSaverAttrRec is allocated, replacing the old struct. The
old struct was freed but not removed from the clients resources.
Later, when the client is destroyed the resource system invokes
ScreenSaverFreeAttr and attempts to clean up the already freed struct.
Fix this by letting the resource system free the old attrs instead.
CVE-2022-46343, ZDI-CAN 19404
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
---
Xext/saver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Xext/saver.c b/Xext/saver.c
index f813ba08d1..fd6153c313 100644
--- a/Xext/saver.c
+++ b/Xext/saver.c
@@ -1051,7 +1051,7 @@ ScreenSaverSetAttributes(ClientPtr client)
pVlist++;
}
if (pPriv->attr)
- FreeScreenAttr(pPriv->attr);
+ FreeResource(pPriv->attr->resource, AttrType);
pPriv->attr = pAttr;
pAttr->resource = FakeClientID(client->index);
if (!AddResource(pAttr->resource, AttrType, (void *) pAttr))
--
2.38.1

74
SOURCES/0006-Xext-free-the-XvRTVideoNotify-when-turning-off-from-.patch
Unescape View File

@ -1,74 +0,0 @@
From a42635ee3c01f71a49052d83a372933504c9db04 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Wed, 30 Nov 2022 11:20:40 +1000
Subject: [PATCH xserver 6/7] Xext: free the XvRTVideoNotify when turning off
from the same client
This fixes a use-after-free bug:
When a client first calls XvdiSelectVideoNotify() on a drawable with a
TRUE onoff argument, a struct XvVideoNotifyRec is allocated. This struct
is added twice to the resources:
- as the drawable's XvRTVideoNotifyList. This happens only once per
drawable, subsequent calls append to this list.
- as the client's XvRTVideoNotify. This happens for every client.
The struct keeps the ClientPtr around once it has been added for a
client. The idea, presumably, is that if the client disconnects we can remove
all structs from the drawable's list that match the client (by resetting
the ClientPtr to NULL), but if the drawable is destroyed we can remove
and free the whole list.
However, if the same client then calls XvdiSelectVideoNotify() on the
same drawable with a FALSE onoff argument, only the ClientPtr on the
existing struct was set to NULL. The struct itself remained in the
client's resources.
If the drawable is now destroyed, the resource system invokes
XvdiDestroyVideoNotifyList which frees the whole list for this drawable
- including our struct. This function however does not free the resource
for the client since our ClientPtr is NULL.
Later, when the client is destroyed and the resource system invokes
XvdiDestroyVideoNotify, we unconditionally set the ClientPtr to NULL. On
a struct that has been freed previously. This is generally frowned upon.
Fix this by calling FreeResource() on the second call instead of merely
setting the ClientPtr to NULL. This removes the struct from the client
resources (but not from the list), ensuring that it won't be accessed
again when the client quits.
Note that the assignment tpn->client = NULL; is superfluous since the
XvdiDestroyVideoNotify function will do this anyway. But it's left for
clarity and to match a similar invocation in XvdiSelectPortNotify.
CVE-2022-46342, ZDI-CAN 19400
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
---
Xext/xvmain.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Xext/xvmain.c b/Xext/xvmain.c
index f627471938..2a08f8744a 100644
--- a/Xext/xvmain.c
+++ b/Xext/xvmain.c
@@ -811,8 +811,10 @@ XvdiSelectVideoNotify(ClientPtr client, DrawablePtr pDraw, BOOL onoff)
tpn = pn;
while (tpn) {
if (tpn->client == client) {
- if (!onoff)
+ if (!onoff) {
tpn->client = NULL;
+ FreeResource(tpn->id, XvRTVideoNotify);
+ }
return Success;
}
if (!tpn->client)
--
2.38.1

36
SOURCES/0007-xkb-reset-the-radio_groups-pointer-to-NULL-after-fre.patch
Unescape View File

@ -1,36 +0,0 @@
From 774260dbae1fa505cd2848c786baed9a8db5179d Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Mon, 5 Dec 2022 15:55:54 +1000
Subject: [PATCH xserver 7/7] xkb: reset the radio_groups pointer to NULL after
freeing it
Unlike other elements of the keymap, this pointer was freed but not
reset. On a subsequent XkbGetKbdByName request, the server may access
already freed memory.
CVE-2022-46283, ZDI-CAN-19530
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
---
xkb/xkbUtils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xkb/xkbUtils.c b/xkb/xkbUtils.c
index dd089c2046..3f5791a183 100644
--- a/xkb/xkbUtils.c
+++ b/xkb/xkbUtils.c
@@ -1326,6 +1326,7 @@ _XkbCopyNames(XkbDescPtr src, XkbDescPtr dst)
}
else {
free(dst->names->radio_groups);
+ dst->names->radio_groups = NULL;
}
dst->names->num_rg = src->names->num_rg;
--
2.38.1

35
SOURCES/0008-Xext-fix-invalid-event-type-mask-in-XTestSwapFakeInp.patch
Unescape View File

@ -1,35 +0,0 @@
From bb1711b7fba42f2a0c7d1c09beee241a1b2bcc30 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Mon, 19 Dec 2022 10:06:45 +1000
Subject: [PATCH xserver] Xext: fix invalid event type mask in
XTestSwapFakeInput
In commit b320ca0 the mask was inadvertently changed from octal 0177 to
hexadecimal 0x177.
Fixes commit b320ca0ffe4c0c872eeb3a93d9bde21f765c7c63
Xtest: disallow GenericEvents in XTestSwapFakeInput
Found by Stuart Cassoff
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
---
Xext/xtest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Xext/xtest.c b/Xext/xtest.c
index 2985a4ce6e..dde5c4cf9d 100644
--- a/Xext/xtest.c
+++ b/Xext/xtest.c
@@ -502,7 +502,7 @@ XTestSwapFakeInput(ClientPtr client, xReq * req)
nev = ((req->length << 2) - sizeof(xReq)) / sizeof(xEvent);
for (ev = (xEvent *) &req[1]; --nev >= 0; ev++) {
- int evtype = ev->u.u.type & 0x177;
+ int evtype = ev->u.u.type & 0177;
/* Swap event */
proc = EventSwapVector[evtype];
/* no swapping proc; invalid event type? */
--
2.38.1

57
SPECS/xorg-x11-server-Xwayland.spec
Unescape View File

@ -8,8 +8,8 @@
Summary: Xwayland
Name: xorg-x11-server-Xwayland
Version: 21.1.3
Release: 7%{?gitdate:.%{gitdate}git%{shortcommit}}%{?dist}
Version: 22.1.9
Release: 2%{?gitdate:.%{gitdate}git%{shortcommit}}%{?dist}
URL: http://www.x.org
%if 0%{?gitdate}
@ -18,46 +18,6 @@ Source0: https://gitlab.freedesktop.org/xorg/%{pkgname}/-/archive/%{commit}/%{
Source0: https://www.x.org/pub/individual/xserver/%{pkgname}-%{version}.tar.xz
%endif
Patch1: 0001-xwayland-eglstream-Demote-EGLstream-device-warning.patch
Patch2: 0002-xwayland-glamor-Change-errors-to-verbose-messages.patch
Patch3: 0003-xwayland-glamor-Log-backend-selected-for-debug.patch
Patch4: 0004-xwayland-eglstream-Prefer-EGLstream-if-available.patch
# CVE-2021-4011
Patch10001: 0001-record-Fix-out-of-bounds-access-in-SwapCreateRegiste.patch
# CVE-2021-4009
Patch10002: 0002-xfixes-Fix-out-of-bounds-access-in-ProcXFixesCreateP.patch
# CVE-2021-4010
Patch10003: 0003-Xext-Fix-out-of-bounds-access-in-SProcScreenSaverSus.patch
# CVE-2021-4008
Patch10004: 0004-render-Fix-out-of-bounds-access-in-SProcRenderCompos.patch
# CVE-2022-2319/ZDI-CAN-16062, CVE-2022-2320/ZDI-CAN-16070
Patch10005: 0001-xkb-switch-to-array-index-loops-to-moving-pointers.patch
Patch10006: 0002-xkb-swap-XkbSetDeviceInfo-and-XkbSetDeviceInfoCheck.patch
Patch10007: 0003-xkb-add-request-length-validation-for-XkbSetGeometry.patch
# CVE-2022-3550
Patch10008: 0001-xkb-proof-GetCountedString-against-request-length-at.patch
# CVE-2022-3551
Patch10009: 0001-xkb-fix-some-possible-memleaks-in-XkbGetKbdByName.patch
# CVE-2022-46340
Patch10010: 0001-Xtest-disallow-GenericEvents-in-XTestSwapFakeInput.patch
# related to CVE-2022-46344
Patch10011: 0002-Xi-return-an-error-from-XI-property-changes-if-verif.patch
# CVE-2022-46344
Patch10012: 0003-Xi-avoid-integer-truncation-in-length-check-of-ProcX.patch
# CVE-2022-46341
Patch10013: 0004-Xi-disallow-passive-grabs-with-a-detail-255.patch
# CVE-2022-46343
Patch10014: 0005-Xext-free-the-screen-saver-resource-when-replacing-i.patch
# CVE-2022-46342
Patch10015: 0006-Xext-free-the-XvRTVideoNotify-when-turning-off-from-.patch
# CVE-2022-46283
Patch10016: 0007-xkb-reset-the-radio_groups-pointer-to-NULL-after-fre.patch
# Follow-up to CVE-2022-46340
Patch10017: 0008-Xext-fix-invalid-event-type-mask-in-XTestSwapFakeInp.patch
# CVE-2023-0494
Patch10018: 0001-Xi-fix-potential-use-after-free-in-DeepCopyPointerCl.patch
License: MIT
Requires: xorg-x11-server-common
@ -68,11 +28,10 @@ BuildRequires: git-core
BuildRequires: meson
BuildRequires: wayland-devel
BuildRequires: pkgconfig(wayland-client) >= 1.3.0
BuildRequires: pkgconfig(wayland-client) >= 1.18.0
BuildRequires: pkgconfig(wayland-protocols)
BuildRequires: pkgconfig(wayland-eglstream-protocols)
BuildRequires: pkgconfig(dmx)
BuildRequires: pkgconfig(epoxy)
BuildRequires: pkgconfig(fontenc)
BuildRequires: pkgconfig(libdrm) >= 2.4.0
@ -97,6 +56,7 @@ BuildRequires: pkgconfig(xshmfence) >= 1.1
BuildRequires: pkgconfig(xtrans) >= 1.3.2
BuildRequires: pkgconfig(xtst)
BuildRequires: pkgconfig(xv)
BuildRequires: pkgconfig(libxcvt)
BuildRequires: xorg-x11-proto-devel >= 7.7-10
BuildRequires: mesa-libGL-devel >= 9.2
@ -163,6 +123,15 @@ rm -Rf $RPM_BUILD_ROOT%{_localstatedir}/lib/xkb
%{_libdir}/pkgconfig/xwayland.pc
%changelog
* Tue Apr 25 2023 Olivier Fourdan <ofourdan@redhat.com> - 22.1.9-2
- Rebuild (#2158761)
* Mon Apr 3 2023 Olivier Fourdan <ofourdan@redhat.com> - 22.1.9-1
- xwayland 22.1.9 (#2158761)
* Fri Mar 31 2023 Olivier Fourdan <ofourdan@redhat.com> - 21.1.3-8
- Fix CVE-2023-1393 (#2180299)
* Tue Feb 7 2023 Olivier Fourdan <ofourdan@redhat.com> - 21.1.3-7
- Fix CVE-2023-0494 (#2166974)

Write Preview
Loading…
Cancel
Save