diff --git a/.gitignore b/.gitignore index ad04534..1aa351b 100644 --- a/.gitignore +++ b/.gitignore @@ -4,3 +4,4 @@ /xwayland-21.1.0.tar.xz /xwayland-21.1.1.tar.xz /xwayland-21.1.3.tar.xz +/xwayland-22.1.9.tar.xz diff --git a/0001-Xi-fix-potential-use-after-free-in-DeepCopyPointerCl.patch b/0001-Xi-fix-potential-use-after-free-in-DeepCopyPointerCl.patch deleted file mode 100644 index 595f75e..0000000 --- a/0001-Xi-fix-potential-use-after-free-in-DeepCopyPointerCl.patch +++ /dev/null @@ -1,36 +0,0 @@ -From 8660dd164882ce5fc1f274427e2ff3dc020d6273 Mon Sep 17 00:00:00 2001 -From: Peter Hutterer -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 -(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 - diff --git a/0001-Xtest-disallow-GenericEvents-in-XTestSwapFakeInput.patch b/0001-Xtest-disallow-GenericEvents-in-XTestSwapFakeInput.patch deleted file mode 100644 index 017f247..0000000 --- a/0001-Xtest-disallow-GenericEvents-in-XTestSwapFakeInput.patch +++ /dev/null @@ -1,52 +0,0 @@ -From 8dba686dc277d6d262ad0c77b4632a5b276697ba Mon Sep 17 00:00:00 2001 -From: Peter Hutterer -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 -Acked-by: Olivier Fourdan ---- - 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 - diff --git a/0001-composite-Fix-use-after-free-of-the-COW.patch b/0001-composite-Fix-use-after-free-of-the-COW.patch deleted file mode 100644 index bb21d7e..0000000 --- a/0001-composite-Fix-use-after-free-of-the-COW.patch +++ /dev/null @@ -1,42 +0,0 @@ -From 26ef545b3502f61ca722a7a3373507e88ef64110 Mon Sep 17 00:00:00 2001 -From: Olivier Fourdan -Date: Mon, 13 Mar 2023 11:08:47 +0100 -Subject: [PATCH xserver] composite: Fix use-after-free of the COW - -ZDI-CAN-19866/CVE-2023-1393 - -If a client explicitly destroys the compositor overlay window (aka COW), -we would leave a dangling pointer to that window in the CompScreen -structure, which will trigger a use-after-free later. - -Make sure to clear the CompScreen pointer to the COW when the latter gets -destroyed explicitly by the client. - -This vulnerability was discovered by: -Jan-Niklas Sohn working with Trend Micro Zero Day Initiative - -Signed-off-by: Olivier Fourdan -Reviewed-by: Adam Jackson ---- - composite/compwindow.c | 5 +++++ - 1 file changed, 5 insertions(+) - -diff --git a/composite/compwindow.c b/composite/compwindow.c -index 4e2494b86..b30da589e 100644 ---- a/composite/compwindow.c -+++ b/composite/compwindow.c -@@ -620,6 +620,11 @@ compDestroyWindow(WindowPtr pWin) - ret = (*pScreen->DestroyWindow) (pWin); - cs->DestroyWindow = pScreen->DestroyWindow; - pScreen->DestroyWindow = compDestroyWindow; -+ -+ /* Did we just destroy the overlay window? */ -+ if (pWin == cs->pOverlayWin) -+ cs->pOverlayWin = NULL; -+ - /* compCheckTree (pWin->drawable.pScreen); can't check -- tree isn't good*/ - return ret; - } --- -2.40.0 - diff --git a/0001-record-Fix-out-of-bounds-access-in-SwapCreateRegiste.patch b/0001-record-Fix-out-of-bounds-access-in-SwapCreateRegiste.patch deleted file mode 100644 index 83e4ce2..0000000 --- a/0001-record-Fix-out-of-bounds-access-in-SwapCreateRegiste.patch +++ /dev/null @@ -1,35 +0,0 @@ -From a8644465d98beb08759546711b77bb617861c67f Mon Sep 17 00:00:00 2001 -From: Povilas Kanapickas -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 -(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 - diff --git a/0001-xkb-fix-some-possible-memleaks-in-XkbGetKbdByName.patch b/0001-xkb-fix-some-possible-memleaks-in-XkbGetKbdByName.patch deleted file mode 100644 index 6e5ebb5..0000000 --- a/0001-xkb-fix-some-possible-memleaks-in-XkbGetKbdByName.patch +++ /dev/null @@ -1,59 +0,0 @@ -From 18f91b950e22c2a342a4fbc55e9ddf7534a707d2 Mon Sep 17 00:00:00 2001 -From: Peter Hutterer -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 ---- - 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 - diff --git a/0001-xkb-proof-GetCountedString-against-request-length-at.patch b/0001-xkb-proof-GetCountedString-against-request-length-at.patch deleted file mode 100644 index d358a32..0000000 --- a/0001-xkb-proof-GetCountedString-against-request-length-at.patch +++ /dev/null @@ -1,35 +0,0 @@ -From 11beef0b7f1ed290348e45618e5fa0d2bffcb72e Mon Sep 17 00:00:00 2001 -From: Peter Hutterer -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 ---- - 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 - diff --git a/0001-xkb-switch-to-array-index-loops-to-moving-pointers.patch b/0001-xkb-switch-to-array-index-loops-to-moving-pointers.patch deleted file mode 100644 index be7b84f..0000000 --- a/0001-xkb-switch-to-array-index-loops-to-moving-pointers.patch +++ /dev/null @@ -1,77 +0,0 @@ -From c9b379ec5a1a34692af06056925bd0fc5f809713 Mon Sep 17 00:00:00 2001 -From: Peter Hutterer -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 -Reviewed-by: Olivier Fourdan -(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 - diff --git a/0001-xwayland-eglstream-Demote-EGLstream-device-warning.patch b/0001-xwayland-eglstream-Demote-EGLstream-device-warning.patch deleted file mode 100644 index 0114bc7..0000000 --- a/0001-xwayland-eglstream-Demote-EGLstream-device-warning.patch +++ /dev/null @@ -1,43 +0,0 @@ -From 0a7ed9ff7ea20f7b958a2ad9f9bd045080a3ad9a Mon Sep 17 00:00:00 2001 -From: Olivier Fourdan -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 -Reviewed-by: Simon Ser -Reviewed-by: Jonas Ådahl -(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 - diff --git a/0002-Xi-return-an-error-from-XI-property-changes-if-verif.patch b/0002-Xi-return-an-error-from-XI-property-changes-if-verif.patch deleted file mode 100644 index 72bcadb..0000000 --- a/0002-Xi-return-an-error-from-XI-property-changes-if-verif.patch +++ /dev/null @@ -1,41 +0,0 @@ -From c5ff57676698f19ed3a1402aef58a15552e32d27 Mon Sep 17 00:00:00 2001 -From: Peter Hutterer -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 -Acked-by: Olivier Fourdan ---- - 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 - diff --git a/0002-xfixes-Fix-out-of-bounds-access-in-ProcXFixesCreateP.patch b/0002-xfixes-Fix-out-of-bounds-access-in-ProcXFixesCreateP.patch deleted file mode 100644 index fe4f283..0000000 --- a/0002-xfixes-Fix-out-of-bounds-access-in-ProcXFixesCreateP.patch +++ /dev/null @@ -1,44 +0,0 @@ -From 3eb5445f6f7fa9f86de87adc768105d42bdbcf74 Mon Sep 17 00:00:00 2001 -From: Povilas Kanapickas -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 -(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 - diff --git a/0002-xkb-swap-XkbSetDeviceInfo-and-XkbSetDeviceInfoCheck.patch b/0002-xkb-swap-XkbSetDeviceInfo-and-XkbSetDeviceInfoCheck.patch deleted file mode 100644 index 26cf147..0000000 --- a/0002-xkb-swap-XkbSetDeviceInfo-and-XkbSetDeviceInfoCheck.patch +++ /dev/null @@ -1,180 +0,0 @@ -From 45a0af83129eb7dc244c5118360afc1972a686c7 Mon Sep 17 00:00:00 2001 -From: Peter Hutterer -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 -(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 - diff --git a/0002-xwayland-glamor-Change-errors-to-verbose-messages.patch b/0002-xwayland-glamor-Change-errors-to-verbose-messages.patch deleted file mode 100644 index ea69f62..0000000 --- a/0002-xwayland-glamor-Change-errors-to-verbose-messages.patch +++ /dev/null @@ -1,88 +0,0 @@ -From a515f4f4336efb8a2adf9a3ac141129708297d80 Mon Sep 17 00:00:00 2001 -From: Olivier Fourdan -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 -Reviewed-by: Jonas Ådahl -(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 - diff --git a/0003-Xext-Fix-out-of-bounds-access-in-SProcScreenSaverSus.patch b/0003-Xext-Fix-out-of-bounds-access-in-SProcScreenSaverSus.patch deleted file mode 100644 index 60f2218..0000000 --- a/0003-Xext-Fix-out-of-bounds-access-in-SProcScreenSaverSus.patch +++ /dev/null @@ -1,34 +0,0 @@ -From fe0c050276c09f43cc1ae80b4553db42398ca84c Mon Sep 17 00:00:00 2001 -From: Povilas Kanapickas -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 -(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 - diff --git a/0003-Xi-avoid-integer-truncation-in-length-check-of-ProcX.patch b/0003-Xi-avoid-integer-truncation-in-length-check-of-ProcX.patch deleted file mode 100644 index d3c6541..0000000 --- a/0003-Xi-avoid-integer-truncation-in-length-check-of-ProcX.patch +++ /dev/null @@ -1,71 +0,0 @@ -From f9c435822c852659e3926502829f1b13ce6efc37 Mon Sep 17 00:00:00 2001 -From: Peter Hutterer -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 -Acked-by: Olivier Fourdan ---- - 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 - diff --git a/0003-xkb-add-request-length-validation-for-XkbSetGeometry.patch b/0003-xkb-add-request-length-validation-for-XkbSetGeometry.patch deleted file mode 100644 index 4200896..0000000 --- a/0003-xkb-add-request-length-validation-for-XkbSetGeometry.patch +++ /dev/null @@ -1,183 +0,0 @@ -From bd134231e282d9eb126b6fdaa40bb383180fa72b Mon Sep 17 00:00:00 2001 -From: Peter Hutterer -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 -(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 - diff --git a/0003-xwayland-glamor-Log-backend-selected-for-debug.patch b/0003-xwayland-glamor-Log-backend-selected-for-debug.patch deleted file mode 100644 index 3d231cd..0000000 --- a/0003-xwayland-glamor-Log-backend-selected-for-debug.patch +++ /dev/null @@ -1,42 +0,0 @@ -From 3206e133cb768709d32f260ac4b1bb17a46141a7 Mon Sep 17 00:00:00 2001 -From: Olivier Fourdan -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 -Reviewed-by: Michel Dänzer -(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 - diff --git a/0004-Xi-disallow-passive-grabs-with-a-detail-255.patch b/0004-Xi-disallow-passive-grabs-with-a-detail-255.patch deleted file mode 100644 index 5b189ea..0000000 --- a/0004-Xi-disallow-passive-grabs-with-a-detail-255.patch +++ /dev/null @@ -1,82 +0,0 @@ -From 0dab0b527ac5c4fe0272ea679522bd87238a733b Mon Sep 17 00:00:00 2001 -From: Peter Hutterer -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 -Acked-by: Olivier Fourdan ---- - 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) - ¶m, 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, -- ¶m, XI2, &mask); -+ status = GrabKey(client, dev, mod_dev, stuff->detail, -+ ¶m, 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 - diff --git a/0004-render-Fix-out-of-bounds-access-in-SProcRenderCompos.patch b/0004-render-Fix-out-of-bounds-access-in-SProcRenderCompos.patch deleted file mode 100644 index 59c0762..0000000 --- a/0004-render-Fix-out-of-bounds-access-in-SProcRenderCompos.patch +++ /dev/null @@ -1,53 +0,0 @@ -From 59c977bff66de77bd93ce8853e33e1b4ca661a49 Mon Sep 17 00:00:00 2001 -From: Povilas Kanapickas -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 -(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 - diff --git a/0004-xwayland-eglstream-Prefer-EGLstream-if-available.patch b/0004-xwayland-eglstream-Prefer-EGLstream-if-available.patch deleted file mode 100644 index a983979..0000000 --- a/0004-xwayland-eglstream-Prefer-EGLstream-if-available.patch +++ /dev/null @@ -1,64 +0,0 @@ -From bdc00ba749ac6cde35c025f5f6b1a5b49c1f4960 Mon Sep 17 00:00:00 2001 -From: Olivier Fourdan -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 -Acked-by: Michel Dänzer -(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 - diff --git a/0005-Xext-free-the-screen-saver-resource-when-replacing-i.patch b/0005-Xext-free-the-screen-saver-resource-when-replacing-i.patch deleted file mode 100644 index dc2a9d9..0000000 --- a/0005-Xext-free-the-screen-saver-resource-when-replacing-i.patch +++ /dev/null @@ -1,48 +0,0 @@ -From 94f6fe99d87cf6ba0adadd95c595158c345b7d29 Mon Sep 17 00:00:00 2001 -From: Peter Hutterer -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 -Acked-by: Olivier Fourdan ---- - 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 - diff --git a/0006-Xext-free-the-XvRTVideoNotify-when-turning-off-from-.patch b/0006-Xext-free-the-XvRTVideoNotify-when-turning-off-from-.patch deleted file mode 100644 index ba8b8fa..0000000 --- a/0006-Xext-free-the-XvRTVideoNotify-when-turning-off-from-.patch +++ /dev/null @@ -1,74 +0,0 @@ -From a42635ee3c01f71a49052d83a372933504c9db04 Mon Sep 17 00:00:00 2001 -From: Peter Hutterer -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 -Acked-by: Olivier Fourdan ---- - 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 - diff --git a/0007-xkb-reset-the-radio_groups-pointer-to-NULL-after-fre.patch b/0007-xkb-reset-the-radio_groups-pointer-to-NULL-after-fre.patch deleted file mode 100644 index c6b2352..0000000 --- a/0007-xkb-reset-the-radio_groups-pointer-to-NULL-after-fre.patch +++ /dev/null @@ -1,36 +0,0 @@ -From 774260dbae1fa505cd2848c786baed9a8db5179d Mon Sep 17 00:00:00 2001 -From: Peter Hutterer -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 -Acked-by: Olivier Fourdan ---- - 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 - diff --git a/0008-Xext-fix-invalid-event-type-mask-in-XTestSwapFakeInp.patch b/0008-Xext-fix-invalid-event-type-mask-in-XTestSwapFakeInp.patch deleted file mode 100644 index c84d387..0000000 --- a/0008-Xext-fix-invalid-event-type-mask-in-XTestSwapFakeInp.patch +++ /dev/null @@ -1,35 +0,0 @@ -From bb1711b7fba42f2a0c7d1c09beee241a1b2bcc30 Mon Sep 17 00:00:00 2001 -From: Peter Hutterer -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 ---- - 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 - diff --git a/sources b/sources index 9f27bc1..0e1fedd 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -SHA512 (xwayland-21.1.3.tar.xz) = 24147ef788cce3fa16cd5604d293ffbe7ef4c6dc5fc2b1a1018d78ca4c0f10ade7b99c1ad6a8cdca5c581ff40f5834d7e34b2a314acca665a527eed700993594 +SHA512 (xwayland-22.1.9.tar.xz) = 4b30c1cfdb18d9a0f55aa8a8324f625ec5bbd67c1e9041956a2e65c1d063b509cd921ecb8d299f9b6f0daaa01b75ae42f1d47f7fecb944a352cc60954c1ad334 diff --git a/xorg-x11-server-Xwayland.spec b/xorg-x11-server-Xwayland.spec index 3e3caa6..5eab861 100644 --- a/xorg-x11-server-Xwayland.spec +++ b/xorg-x11-server-Xwayland.spec @@ -8,8 +8,8 @@ Summary: Xwayland Name: xorg-x11-server-Xwayland -Version: 21.1.3 -Release: 8%{?gitdate:.%{gitdate}git%{shortcommit}}%{?dist} +Version: 22.1.9 +Release: 1%{?gitdate:.%{gitdate}git%{shortcommit}}%{?dist} URL: http://www.x.org %if 0%{?gitdate} @@ -18,48 +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 -# CVE-2023-1393 -Patch10019: 0001-composite-Fix-use-after-free-of-the-COW.patch - License: MIT Requires: xorg-x11-server-common @@ -70,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 @@ -99,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 @@ -165,6 +123,9 @@ rm -Rf $RPM_BUILD_ROOT%{_localstatedir}/lib/xkb %{_libdir}/pkgconfig/xwayland.pc %changelog +* Mon Apr 3 2023 Olivier Fourdan - 22.1.9-1 +- xwayland 22.1.9 (#2158761) + * Fri Mar 31 2023 Olivier Fourdan - 21.1.3-8 - Fix CVE-2023-1393 (#2180299)