xorg-server-xvfb: Bump to 21.1.6

This commit is contained in:
Tee KOBAYASHI 2023-01-18 21:28:08 +09:00 committed by xtkoba
parent 07b95fcbf2
commit 0e6a167082
15 changed files with 14 additions and 1016 deletions

View File

@ -1,250 +0,0 @@
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 a29262c244..64e52611ee 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];
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 34b2c290be..4692895dbd 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;

View File

@ -1,175 +0,0 @@
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 64e52611ee..34b2c290be 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;

View File

@ -1,34 +0,0 @@
From 11beef0b7f1ed290348e45618e5fa0d2bffcb72e Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue, 5 Jul 2022 12:06:20 +1000
Subject: 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

View File

@ -1,59 +0,0 @@
From 18f91b950e22c2a342a4fbc55e9ddf7534a707d2 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Wed, 13 Jul 2022 11:23:09 +1000
Subject: 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

View File

@ -1,36 +0,0 @@
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 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-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;
--
2.38.0

View File

@ -1,51 +0,0 @@
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 1/7] Xtest: disallow GenericEvents in XTestSwapFakeInput
XTestSwapFakeInput assumes all events in this request are
sizeof(xEvent) and iterates through these in 32-byte increments.
However, a GenericEvent may be of arbitrary length longer than 32 bytes,
so any GenericEvent in this list would result in subsequent events to be
misparsed.
Additional, the swapped event is written into a stack-allocated struct
xEvent (size 32 bytes). For any GenericEvent longer than 32 bytes,
swapping the event may thus smash the stack like an avocado on toast.
Catch this case early and return BadValue for any GenericEvent.
Which is what would happen in unswapped setups anyway since XTest
doesn't support GenericEvent.
CVE-2022-46340, ZDI-CAN 19265
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
---
Xext/xtest.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Xext/xtest.c b/Xext/xtest.c
index 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;
}
--
2.38.0

View File

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

View File

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

View File

@ -1,47 +0,0 @@
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 4/7] Xext: free the screen saver resource when replacing it
This fixes a use-after-free bug:
When a client first calls ScreenSaverSetAttributes(), a struct
ScreenSaverAttrRec is allocated and added to the client's
resources.
When the same client calls ScreenSaverSetAttributes() again, a new
struct ScreenSaverAttrRec is allocated, replacing the old struct. The
old struct was freed but not removed from the clients resources.
Later, when the client is destroyed the resource system invokes
ScreenSaverFreeAttr and attempts to clean up the already freed struct.
Fix this by letting the resource system free the old attrs instead.
CVE-2022-46343, ZDI-CAN 19404
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
---
Xext/saver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Xext/saver.c b/Xext/saver.c
index 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))
--
2.38.0

View File

@ -1,112 +0,0 @@
From b8a84cb0f2807b07ab70ca9915fcdee21301b8ca Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue, 29 Nov 2022 13:24:00 +1000
Subject: [PATCH 5/7] Xi: return an error from XI property changes if
verification failed
Both ProcXChangeDeviceProperty and ProcXIChangeProperty checked the
property for validity but didn't actually return the potential error.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
---
Xi/xiproperty.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
index a36f7d61d..68c362c62 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.0
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 6/7] Xi: avoid integer truncation in length check of
ProcXIChangeProperty
This fixes an OOB read and the resulting information disclosure.
Length calculation for the request was clipped to a 32-bit integer. With
the correct stuff->num_items value the expected request size was
truncated, passing the REQUEST_FIXED_SIZE check.
The server then proceeded with reading at least stuff->num_items bytes
(depending on stuff->format) from the request and stuffing whatever it
finds into the property. In the process it would also allocate at least
stuff->num_items bytes, i.e. 4GB.
The same bug exists in ProcChangeProperty and ProcXChangeDeviceProperty,
so let's fix that too.
CVE-2022-46344, ZDI-CAN 19405
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
---
Xi/xiproperty.c | 4 ++--
dix/property.c | 3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
index 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);
--
2.38.0

View File

@ -2,10 +2,9 @@ TERMUX_PKG_HOMEPAGE=https://xorg.freedesktop.org/
TERMUX_PKG_DESCRIPTION="X virtual framebuffer"
TERMUX_PKG_LICENSE="MIT"
TERMUX_PKG_MAINTAINER="@termux"
TERMUX_PKG_VERSION=1.20.14
TERMUX_PKG_REVISION=3
TERMUX_PKG_VERSION=21.1.6
TERMUX_PKG_SRCURL=https://xorg.freedesktop.org/releases/individual/xserver/xorg-server-${TERMUX_PKG_VERSION}.tar.xz
TERMUX_PKG_SHA256=5cc5b70b9be89443e2594b93656c60bd5e82cd7f01deb4ce4faf81dcf546a16b
TERMUX_PKG_SHA256=1eb86ed674d042b6c8b1f9135e59395cbbca35ed551b122f73a7d8bb3bb22484
TERMUX_PKG_DEPENDS="libandroid-shmem, libdrm, libpixman, libx11, libxau, libxfont2, libxinerama, libxkbfile, libxshmfence, mesa, openssl, xkeyboard-config, xorg-protocol-txt, xorg-xkbcomp"
TERMUX_PKG_CONFLICTS="xorg-xvfb"

View File

@ -1,69 +1,12 @@
diff -uNr xorg-server-1.20.1/hw/xfree86/parser/write.c xorg-server-1.20.1.mod/hw/xfree86/parser/write.c
--- xorg-server-1.20.1/hw/xfree86/parser/write.c 2018-08-07 19:31:03.000000000 +0300
+++ xorg-server-1.20.1.mod/hw/xfree86/parser/write.c 2018-10-08 21:07:16.817587230 +0300
@@ -129,64 +129,5 @@
@@ -129,7 +129,7 @@
int
xf86writeConfigFile(const char *filename, XF86ConfigPtr cptr)
{
-#ifndef HAS_NO_UIDS
- int ret;
-
- if (getuid() != geteuid()) {
-
-#if !defined(HAS_SAVED_IDS_AND_SETEUID)
- int pid, p;
- int status;
- void (*csig) (int);
-
- /* Need to fork to change ruid without loosing euid */
- csig = OsSignal(SIGCHLD, SIG_DFL);
- switch ((pid = fork())) {
- case -1:
- ErrorF("xf86writeConfigFile(): fork failed (%s)\n",
- strerror(errno));
- return 0;
- case 0: /* child */
- if (setuid(getuid()) == -1)
- FatalError("xf86writeConfigFile(): "
- "setuid failed(%s)\n", strerror(errno));
- ret = doWriteConfigFile(filename, cptr);
- exit(ret);
- break;
- default: /* parent */
- do {
- p = waitpid(pid, &status, 0);
- } while (p == -1 && errno == EINTR);
- }
- OsSignal(SIGCHLD, csig);
- if (p != -1 && WIFEXITED(status) && WEXITSTATUS(status) == 0)
- return 1; /* success */
- else
- return 0;
-
-#else /* HAS_SAVED_IDS_AND_SETEUID */
- int ruid, euid;
-
- ruid = getuid();
- euid = geteuid();
-
- if (seteuid(ruid) == -1) {
- ErrorF("xf86writeConfigFile(): seteuid(%d) failed (%s)\n",
- ruid, strerror(errno));
- return 0;
- }
- ret = doWriteConfigFile(filename, cptr);
-
- if (seteuid(euid) == -1) {
- ErrorF("xf86writeConfigFile(): seteuid(%d) failed (%s)\n",
- euid, strerror(errno));
- }
- return ret;
-
-#endif /* HAS_SAVED_IDS_AND_SETEUID */
-
- }
- else
-#endif /* !HAS_NO_UIDS */
- return doWriteConfigFile(filename, cptr);
+ return doWriteConfigFile(filename, cptr);
}
+#if !defined(HAS_NO_UIDS) && !defined(__ANDROID__)
int ret;
if (getuid() != geteuid()) {

View File

@ -1,12 +0,0 @@
diff -uNr xorg-server-1.20.1/include/site.h xorg-server-1.20.1.mod/include/site.h
--- xorg-server-1.20.1/include/site.h 2018-08-07 19:31:05.000000000 +0300
+++ xorg-server-1.20.1.mod/include/site.h 2018-10-08 21:07:16.824256995 +0300
@@ -72,7 +72,7 @@
* DO NOT CHANGE THESE VALUES OR THE DIX IMAKEFILE!
*/
#ifndef COMPILEDDEFAULTFONTPATH
-#define COMPILEDDEFAULTFONTPATH "/usr/share/fonts/X11/misc/"
+#define COMPILEDDEFAULTFONTPATH "@TERMUX_PREFIX@/share/fonts/X11/misc/"
#endif
/*

View File

@ -1,12 +0,0 @@
diff -uNr xorg-server-1.20.1/os/connection.c xorg-server-1.20.1.mod/os/connection.c
--- xorg-server-1.20.1/os/connection.c 2018-08-07 19:31:05.000000000 +0300
+++ xorg-server-1.20.1.mod/os/connection.c 2018-10-08 21:07:16.837596523 +0300
@@ -996,7 +996,7 @@
XtransConnInfo ciptr;
const char *display_env = getenv("DISPLAY");
- if (display_env && (strncmp(display_env, "/tmp/launch", 11) == 0)) {
+ if (display_env && (strncmp(display_env, "@TERMUX_PREFIX@/tmp/launch", 11) == 0)) {
/* Make the path the launchd socket if our DISPLAY is set right */
strcpy(port, display_env);
}

View File

@ -2,13 +2,13 @@ diff -uNr xorg-server-1.20.1/xkb/ddxLoad.c xorg-server-1.20.1.mod/xkb/ddxLoad.c
--- xorg-server-1.20.1/xkb/ddxLoad.c 2018-08-07 19:31:06.000000000 +0300
+++ xorg-server-1.20.1.mod/xkb/ddxLoad.c 2018-10-08 21:07:16.844266287 +0300
@@ -76,8 +76,8 @@
}
else
#endif
- if (strlen("/tmp/") < size) {
- (void) strcpy(outdir, "/tmp/");
+ if (strlen("@TERMUX_PREFIX@/tmp/") < size) {
+ (void) strcpy(outdir, "@TERMUX_PREFIX@/tmp/");
if (directory)
r = snprintf(outdir, size, "%s%s", directory, pathsep);
if (r < 0 || r >= size) {
- assert(strlen("/tmp/") < size);
- strcpy(outdir, "/tmp/");
+ assert(strlen("@TERMUX_PREFIX@/tmp/") < size);
+ strcpy(outdir, "@TERMUX_PREFIX@/tmp/");
}
}