diff options
Diffstat (limited to 'extra/source/tigervnc/patches/xorg-server')
18 files changed, 1241 insertions, 0 deletions
diff --git a/extra/source/tigervnc/patches/xorg-server/0001-f1070c01d616c5f21f939d5ebc533738779451ac.patch b/extra/source/tigervnc/patches/xorg-server/0001-f1070c01d616c5f21f939d5ebc533738779451ac.patch new file mode 100644 index 000000000..0efddcf56 --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/0001-f1070c01d616c5f21f939d5ebc533738779451ac.patch @@ -0,0 +1,75 @@ +From f1070c01d616c5f21f939d5ebc533738779451ac 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] 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> +--- + xkb/xkb.c | 20 ++++++++++---------- + 1 file changed, 10 insertions(+), 10 deletions(-) + +diff --git a/xkb/xkb.c b/xkb/xkb.c +index a29262c24..64e52611e 100644 +--- a/xkb/xkb.c ++++ b/xkb/xkb.c +@@ -5368,16 +5368,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); +@@ -5389,7 +5389,7 @@ _CheckSetSections(XkbGeometryPtr geom, + return BadMatch; + } + } +- rWire = (xkbRowWireDesc *) &kWire[rWire->nKeys]; ++ rWire = (xkbRowWireDesc *)kWire; + } + wire = (char *) rWire; + if (sWire->nDoodads > 0) { +@@ -5454,16 +5454,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]; +-- +GitLab + diff --git a/extra/source/tigervnc/patches/xorg-server/0002-dd8caf39e9e15d8f302e54045dd08d8ebf1025dc.patch b/extra/source/tigervnc/patches/xorg-server/0002-dd8caf39e9e15d8f302e54045dd08d8ebf1025dc.patch new file mode 100644 index 000000000..72d30f36b --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/0002-dd8caf39e9e15d8f302e54045dd08d8ebf1025dc.patch @@ -0,0 +1,178 @@ +From dd8caf39e9e15d8f302e54045dd08d8ebf1025dc 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] 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> +--- + xkb/xkb.c | 46 +++++++++++++++++++++++++--------------------- + 1 file changed, 25 insertions(+), 21 deletions(-) + +diff --git a/xkb/xkb.c b/xkb/xkb.c +index 64e52611e..34b2c290b 100644 +--- a/xkb/xkb.c ++++ b/xkb/xkb.c +@@ -6550,7 +6550,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; +@@ -6558,6 +6559,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); +@@ -6585,6 +6591,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); + } +@@ -6596,6 +6607,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); +@@ -6647,11 +6662,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); +@@ -6670,10 +6680,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; +@@ -6691,10 +6697,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; +@@ -6730,13 +6732,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; +@@ -6747,13 +6753,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; + } +@@ -6764,8 +6770,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; +@@ -6789,8 +6795,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; +-- +GitLab + diff --git a/extra/source/tigervnc/patches/xorg-server/0003-6907b6ea2b4ce949cb07271f5b678d5966d9df42.patch b/extra/source/tigervnc/patches/xorg-server/0003-6907b6ea2b4ce949cb07271f5b678d5966d9df42.patch new file mode 100644 index 000000000..11121070b --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/0003-6907b6ea2b4ce949cb07271f5b678d5966d9df42.patch @@ -0,0 +1,181 @@ +From 6907b6ea2b4ce949cb07271f5b678d5966d9df42 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] 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> +--- + xkb/xkb.c | 43 ++++++++++++++++++++++++++++++++++++++----- + 1 file changed, 38 insertions(+), 5 deletions(-) + +diff --git a/xkb/xkb.c b/xkb/xkb.c +index 34b2c290b..4692895db 100644 +--- a/xkb/xkb.c ++++ b/xkb/xkb.c +@@ -5156,7 +5156,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; +@@ -5167,6 +5167,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) { +@@ -5269,7 +5272,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; +@@ -5280,6 +5283,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); + } +@@ -5291,6 +5297,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); +@@ -5299,6 +5308,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) { +@@ -5332,6 +5344,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); +@@ -5357,6 +5372,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); +@@ -5371,6 +5389,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; +@@ -5396,7 +5417,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; + } +@@ -5405,7 +5426,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; + } +@@ -5439,6 +5460,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) +@@ -5449,12 +5473,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) { +@@ -5560,12 +5590,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; +-- +GitLab + diff --git a/extra/source/tigervnc/patches/xorg-server/857.patch b/extra/source/tigervnc/patches/xorg-server/857.patch new file mode 100644 index 000000000..aad6394c4 --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/857.patch @@ -0,0 +1,43 @@ +From d2ce97bd02c16ae162c49f76a00fc858035f288e Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?B=C5=82a=C5=BCej=20Szczygie=C5=82?= <spaz16@wp.pl> +Date: Thu, 13 Jan 2022 00:47:27 +0100 +Subject: [PATCH] present: Check for NULL to prevent crash +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1275 +Signed-off-by: Błażej Szczygieł <spaz16@wp.pl> +Tested-by: Aaron Plattner <aplattner@nvidia.com> +(cherry picked from commit 22d5818851967408bb7c903cb345b7ca8766094c) +--- + present/present_scmd.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +diff --git a/present/present_scmd.c b/present/present_scmd.c +index 3c68e690b..11391adbb 100644 +--- a/present/present_scmd.c ++++ b/present/present_scmd.c +@@ -168,6 +168,9 @@ present_scmd_get_crtc(present_screen_priv_ptr screen_priv, WindowPtr window) + if (!screen_priv->info) + return NULL; + ++ if (!screen_priv->info->get_crtc) ++ return NULL; ++ + return (*screen_priv->info->get_crtc)(window); + } + +@@ -206,6 +209,9 @@ present_flush(WindowPtr window) + if (!screen_priv->info) + return; + ++ if (!screen_priv->info->flush) ++ return; ++ + (*screen_priv->info->flush) (window); + } + +-- +GitLab + diff --git a/extra/source/tigervnc/patches/xorg-server/CVE-2022-3550.patch b/extra/source/tigervnc/patches/xorg-server/CVE-2022-3550.patch new file mode 100644 index 000000000..3461b0749 --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/CVE-2022-3550.patch @@ -0,0 +1,34 @@ +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: 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); +-- +cgit v1.2.1 + diff --git a/extra/source/tigervnc/patches/xorg-server/CVE-2022-3551.patch b/extra/source/tigervnc/patches/xorg-server/CVE-2022-3551.patch new file mode 100644 index 000000000..e41db9286 --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/CVE-2022-3551.patch @@ -0,0 +1,59 @@ +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: 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); +-- +cgit v1.2.1 + diff --git a/extra/source/tigervnc/patches/xorg-server/CVE-2022-3553.patch b/extra/source/tigervnc/patches/xorg-server/CVE-2022-3553.patch new file mode 100644 index 000000000..593545d03 --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/CVE-2022-3553.patch @@ -0,0 +1,43 @@ +From dfd057996b26420309c324ec844a5ba6dd07eda3 Mon Sep 17 00:00:00 2001 +From: Jeremy Huddleston Sequoia <jeremyhu@apple.com> +Date: Sat, 2 Jul 2022 14:17:18 -0700 +Subject: xquartz: Fix a possible crash when editing the Application menu due + to mutaing immutable arrays + +Crashing on exception: -[__NSCFArray replaceObjectAtIndex:withObject:]: mutating method sent to immutable object + +Application Specific Backtrace 0: +0 CoreFoundation 0x00007ff80d2c5e9b __exceptionPreprocess + 242 +1 libobjc.A.dylib 0x00007ff80d027e48 objc_exception_throw + 48 +2 CoreFoundation 0x00007ff80d38167b _CFThrowFormattedException + 194 +3 CoreFoundation 0x00007ff80d382a25 -[__NSCFArray removeObjectAtIndex:].cold.1 + 0 +4 CoreFoundation 0x00007ff80d2e6c0b -[__NSCFArray replaceObjectAtIndex:withObject:] + 119 +5 X11.bin 0x00000001003180f9 -[X11Controller tableView:setObjectValue:forTableColumn:row:] + 169 + +Fixes: https://github.com/XQuartz/XQuartz/issues/267 +Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com> +--- + hw/xquartz/X11Controller.m | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +diff --git a/hw/xquartz/X11Controller.m b/hw/xquartz/X11Controller.m +index 3b55bb6a5..e9a939312 100644 +--- a/hw/xquartz/X11Controller.m ++++ b/hw/xquartz/X11Controller.m +@@ -469,8 +469,11 @@ extern char *bundle_id_prefix; + self.table_apps = table_apps; + + NSArray * const apps = self.apps; +- if (apps != nil) +- [table_apps addObjectsFromArray:apps]; ++ if (apps != nil) { ++ for (NSArray <NSString *> * row in apps) { ++ [table_apps addObject:row.mutableCopy]; ++ } ++ } + + columns = [apps_table tableColumns]; + [[columns objectAtIndex:0] setIdentifier:@"0"]; +-- +cgit v1.2.1 + diff --git a/extra/source/tigervnc/patches/xorg-server/CVE-2022-4283.patch b/extra/source/tigervnc/patches/xorg-server/CVE-2022-4283.patch new file mode 100644 index 000000000..88dfea0af --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/CVE-2022-4283.patch @@ -0,0 +1,35 @@ +From ccdd431cd8f1cabae9d744f0514b6533c438908c 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] 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-4283, 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 dd089c204..3f5791a18 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; + +-- +GitLab + diff --git a/extra/source/tigervnc/patches/xorg-server/CVE-2022-46340.correction.patch b/extra/source/tigervnc/patches/xorg-server/CVE-2022-46340.correction.patch new file mode 100644 index 000000000..ad31c7916 --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/CVE-2022-46340.correction.patch @@ -0,0 +1,12 @@ +diff -u -r --new-file xorg-server-21.1.5/Xext/xtest.c xorg-server-21.1.6/Xext/xtest.c +--- xorg-server-21.1.5/Xext/xtest.c 2022-12-13 20:25:18.000000000 -0600 ++++ xorg-server-21.1.6/Xext/xtest.c 2022-12-19 04:53:03.000000000 -0600 +@@ -502,7 +502,7 @@ + + 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? */ diff --git a/extra/source/tigervnc/patches/xorg-server/CVE-2022-46340.patch b/extra/source/tigervnc/patches/xorg-server/CVE-2022-46340.patch new file mode 100644 index 000000000..c9bf7bc9f --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/CVE-2022-46340.patch @@ -0,0 +1,51 @@ +From b320ca0ffe4c0c872eeb3a93d9bde21f765c7c63 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] 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 bf27eb590..2985a4ce6 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; + } +-- +GitLab + diff --git a/extra/source/tigervnc/patches/xorg-server/CVE-2022-46341.patch b/extra/source/tigervnc/patches/xorg-server/CVE-2022-46341.patch new file mode 100644 index 000000000..d68fad74d --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/CVE-2022-46341.patch @@ -0,0 +1,82 @@ +From 51eb63b0ee1509c6c6b8922b0e4aa037faa6f78b 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] 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 2769fb7c9..c9ac2f855 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; +-- +GitLab + diff --git a/extra/source/tigervnc/patches/xorg-server/CVE-2022-46342.patch b/extra/source/tigervnc/patches/xorg-server/CVE-2022-46342.patch new file mode 100644 index 000000000..c64a0fbff --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/CVE-2022-46342.patch @@ -0,0 +1,74 @@ +From b79f32b57cc0c1186b2899bce7cf89f7b325161b 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] 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 f62747193..2a08f8744 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) +-- +GitLab + diff --git a/extra/source/tigervnc/patches/xorg-server/CVE-2022-46343.patch b/extra/source/tigervnc/patches/xorg-server/CVE-2022-46343.patch new file mode 100644 index 000000000..3f2d0259b --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/CVE-2022-46343.patch @@ -0,0 +1,47 @@ +From 842ca3ccef100ce010d1d8f5f6d6cc1915055900 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] 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 f813ba08d..fd6153c31 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)) +-- +GitLab + diff --git a/extra/source/tigervnc/patches/xorg-server/CVE-2022-46344.patch b/extra/source/tigervnc/patches/xorg-server/CVE-2022-46344.patch new file mode 100644 index 000000000..966a9cb0e --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/CVE-2022-46344.patch @@ -0,0 +1,71 @@ +From 8f454b793e1f13c99872c15f0eed1d7f3b823fe8 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] 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 68c362c62..066ba21fb 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 94ef5a0ec..acce94b2c 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); + +-- +GitLab + diff --git a/extra/source/tigervnc/patches/xorg-server/CVE-2023-0494.patch b/extra/source/tigervnc/patches/xorg-server/CVE-2023-0494.patch new file mode 100644 index 000000000..96ed78361 --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/CVE-2023-0494.patch @@ -0,0 +1,34 @@ +From 0ba6d8c37071131a49790243cdac55392ecf71ec 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] 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> +--- + 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)); +-- +GitLab + diff --git a/extra/source/tigervnc/patches/xorg-server/CVE-2023-1393.patch b/extra/source/tigervnc/patches/xorg-server/CVE-2023-1393.patch new file mode 100644 index 000000000..0d859d6c1 --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/CVE-2023-1393.patch @@ -0,0 +1,42 @@ +From 26ef545b3502f61ca722a7a3373507e88ef64110 Mon Sep 17 00:00:00 2001 +From: Olivier Fourdan <ofourdan@redhat.com> +Date: Mon, 13 Mar 2023 11:08:47 +0100 +Subject: [PATCH] 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 <ofourdan@redhat.com> +Reviewed-by: Adam Jackson <ajax@redhat.com> +--- + composite/compwindow.c | 5 +++++ + 1 file changed, 5 insertions(+) + +diff --git a/composite/compwindow.c b/composite/compwindow.c +index 4e2494b86b..b30da589e9 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; + } +-- +GitLab + diff --git a/extra/source/tigervnc/patches/xorg-server/CVE-2023-5367.patch b/extra/source/tigervnc/patches/xorg-server/CVE-2023-5367.patch new file mode 100644 index 000000000..aef25e917 --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/CVE-2023-5367.patch @@ -0,0 +1,81 @@ +From 541ab2ecd41d4d8689e71855d93e492bc554719a Mon Sep 17 00:00:00 2001 +From: Peter Hutterer <peter.hutterer@who-t.net> +Date: Tue, 3 Oct 2023 11:53:05 +1000 +Subject: [PATCH] Xi/randr: fix handling of PropModeAppend/Prepend + +The handling of appending/prepending properties was incorrect, with at +least two bugs: the property length was set to the length of the new +part only, i.e. appending or prepending N elements to a property with P +existing elements always resulted in the property having N elements +instead of N + P. + +Second, when pre-pending a value to a property, the offset for the old +values was incorrect, leaving the new property with potentially +uninitalized values and/or resulting in OOB memory writes. +For example, prepending a 3 element value to a 5 element property would +result in this 8 value array: + [N, N, N, ?, ?, P, P, P ] P, P + ^OOB write + +The XI2 code is a copy/paste of the RandR code, so the bug exists in +both. + +CVE-2023-5367, ZDI-CAN-22153 + +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> +--- + Xi/xiproperty.c | 4 ++-- + randr/rrproperty.c | 4 ++-- + 2 files changed, 4 insertions(+), 4 deletions(-) + +diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c +index 066ba21fba..d315f04d0e 100644 +--- a/Xi/xiproperty.c ++++ b/Xi/xiproperty.c +@@ -730,7 +730,7 @@ XIChangeDeviceProperty(DeviceIntPtr dev, Atom property, Atom type, + XIDestroyDeviceProperty(prop); + return BadAlloc; + } +- new_value.size = len; ++ new_value.size = total_len; + new_value.type = type; + new_value.format = format; + +@@ -747,7 +747,7 @@ XIChangeDeviceProperty(DeviceIntPtr dev, Atom property, Atom type, + case PropModePrepend: + new_data = new_value.data; + old_data = (void *) (((char *) new_value.data) + +- (prop_value->size * size_in_bytes)); ++ (len * size_in_bytes)); + break; + } + if (new_data) +diff --git a/randr/rrproperty.c b/randr/rrproperty.c +index c2fb9585c6..25469f57b2 100644 +--- a/randr/rrproperty.c ++++ b/randr/rrproperty.c +@@ -209,7 +209,7 @@ RRChangeOutputProperty(RROutputPtr output, Atom property, Atom type, + RRDestroyOutputProperty(prop); + return BadAlloc; + } +- new_value.size = len; ++ new_value.size = total_len; + new_value.type = type; + new_value.format = format; + +@@ -226,7 +226,7 @@ RRChangeOutputProperty(RROutputPtr output, Atom property, Atom type, + case PropModePrepend: + new_data = new_value.data; + old_data = (void *) (((char *) new_value.data) + +- (prop_value->size * size_in_bytes)); ++ (len * size_in_bytes)); + break; + } + if (new_data) +-- +GitLab + + diff --git a/extra/source/tigervnc/patches/xorg-server/CVE-2023-5380.patch b/extra/source/tigervnc/patches/xorg-server/CVE-2023-5380.patch new file mode 100644 index 000000000..a358076dc --- /dev/null +++ b/extra/source/tigervnc/patches/xorg-server/CVE-2023-5380.patch @@ -0,0 +1,99 @@ +From 564ccf2ce9616620456102727acb8b0256b7bbd7 Mon Sep 17 00:00:00 2001 +From: Peter Hutterer <peter.hutterer@who-t.net> +Date: Thu, 5 Oct 2023 12:19:45 +1000 +Subject: [PATCH] mi: reset the PointerWindows reference on screen switch + +PointerWindows[] keeps a reference to the last window our sprite +entered - changes are usually handled by CheckMotion(). + +If we switch between screens via XWarpPointer our +dev->spriteInfo->sprite->win is set to the new screen's root window. +If there's another window at the cursor location CheckMotion() will +trigger the right enter/leave events later. If there is not, it skips +that process and we never trigger LeaveWindow() - PointerWindows[] for +the device still refers to the previous window. + +If that window is destroyed we have a dangling reference that will +eventually cause a use-after-free bug when checking the window hierarchy +later. + +To trigger this, we require: +- two protocol screens +- XWarpPointer to the other screen's root window +- XDestroyWindow before entering any other window + +This is a niche bug so we hack around it by making sure we reset the +PointerWindows[] entry so we cannot have a dangling pointer. This +doesn't handle Enter/Leave events correctly but the previous code didn't +either. + +CVE-2023-5380, ZDI-CAN-21608 + +This vulnerability was discovered by: +Sri working with Trend Micro Zero Day Initiative + +Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> +Reviewed-by: Adam Jackson <ajax@redhat.com> +--- + dix/enterleave.h | 2 -- + include/eventstr.h | 3 +++ + mi/mipointer.c | 17 +++++++++++++++-- + 3 files changed, 18 insertions(+), 4 deletions(-) + +diff --git a/dix/enterleave.h b/dix/enterleave.h +index 4b833d8a3b..e8af924c68 100644 +--- a/dix/enterleave.h ++++ b/dix/enterleave.h +@@ -58,8 +58,6 @@ extern void DeviceFocusEvent(DeviceIntPtr dev, + + extern void EnterWindow(DeviceIntPtr dev, WindowPtr win, int mode); + +-extern void LeaveWindow(DeviceIntPtr dev); +- + extern void CoreFocusEvent(DeviceIntPtr kbd, + int type, int mode, int detail, WindowPtr pWin); + +diff --git a/include/eventstr.h b/include/eventstr.h +index 93308f9b24..a9926eaeef 100644 +--- a/include/eventstr.h ++++ b/include/eventstr.h +@@ -335,4 +335,7 @@ union _InternalEvent { + GestureEvent gesture_event; + }; + ++extern void ++LeaveWindow(DeviceIntPtr dev); ++ + #endif +diff --git a/mi/mipointer.c b/mi/mipointer.c +index a638f25d4a..8cf0035140 100644 +--- a/mi/mipointer.c ++++ b/mi/mipointer.c +@@ -397,8 +397,21 @@ miPointerWarpCursor(DeviceIntPtr pDev, ScreenPtr pScreen, int x, int y) + #ifdef PANORAMIX + && noPanoramiXExtension + #endif +- ) +- UpdateSpriteForScreen(pDev, pScreen); ++ ) { ++ DeviceIntPtr master = GetMaster(pDev, MASTER_POINTER); ++ /* Hack for CVE-2023-5380: if we're moving ++ * screens PointerWindows[] keeps referring to the ++ * old window. If that gets destroyed we have a UAF ++ * bug later. Only happens when jumping from a window ++ * to the root window on the other screen. ++ * Enter/Leave events are incorrect for that case but ++ * too niche to fix. ++ */ ++ LeaveWindow(pDev); ++ if (master) ++ LeaveWindow(master); ++ UpdateSpriteForScreen(pDev, pScreen); ++ } + } + + /** +-- +GitLab + +B |