23869c61c1
Fix for CVE-2023-6816, CVE-2024-0229, CVE-2024-21885, CVE-2024-21886, CVE-2024-0408, CVE-2024-0409 Resolves: https://issues.redhat.com/browse/RHEL-20379 Resolves: https://issues.redhat.com/browse/RHEL-20385 Resolves: https://issues.redhat.com/browse/RHEL-20529 Resolves: https://issues.redhat.com/browse/RHEL-21194 Resolves: https://issues.redhat.com/browse/RHEL-21204 Resolves: https://issues.redhat.com/browse/RHEL-21211
112 lines
3.5 KiB
Diff
112 lines
3.5 KiB
Diff
From 7efd09cdb13ae1a4100f68a11947afe581fa1ee8 Mon Sep 17 00:00:00 2001
|
|
From: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Date: Thu, 4 Jan 2024 10:01:24 +1000
|
|
Subject: [PATCH xserver 5/9] Xi: flush hierarchy events after adding/removing
|
|
master devices
|
|
|
|
The `XISendDeviceHierarchyEvent()` function allocates space to store up
|
|
to `MAXDEVICES` (256) `xXIHierarchyInfo` structures in `info`.
|
|
|
|
If a device with a given ID was removed and a new device with the same
|
|
ID added both in the same operation, the single device ID will lead to
|
|
two info structures being written to `info`.
|
|
|
|
Since this case can occur for every device ID at once, a total of two
|
|
times `MAXDEVICES` info structures might be written to the allocation.
|
|
|
|
To avoid it, once one add/remove master is processed, send out the
|
|
device hierarchy event for the current state and continue. That event
|
|
thus only ever has exactly one of either added/removed in it (and
|
|
optionally slave attached/detached).
|
|
|
|
CVE-2024-21885, ZDI-CAN-22744
|
|
|
|
This vulnerability was discovered by:
|
|
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
|
|
|
|
(cherry picked from commit 4a5e9b1895627d40d26045bd0b7ef3dce503cbd1)
|
|
---
|
|
Xi/xichangehierarchy.c | 27 ++++++++++++++++++++++-----
|
|
1 file changed, 22 insertions(+), 5 deletions(-)
|
|
|
|
diff --git a/Xi/xichangehierarchy.c b/Xi/xichangehierarchy.c
|
|
index d2d985848..72d00451e 100644
|
|
--- a/Xi/xichangehierarchy.c
|
|
+++ b/Xi/xichangehierarchy.c
|
|
@@ -416,6 +416,11 @@ ProcXIChangeHierarchy(ClientPtr client)
|
|
size_t len; /* length of data remaining in request */
|
|
int rc = Success;
|
|
int flags[MAXDEVICES] = { 0 };
|
|
+ enum {
|
|
+ NO_CHANGE,
|
|
+ FLUSH,
|
|
+ CHANGED,
|
|
+ } changes = NO_CHANGE;
|
|
|
|
REQUEST(xXIChangeHierarchyReq);
|
|
REQUEST_AT_LEAST_SIZE(xXIChangeHierarchyReq);
|
|
@@ -465,8 +470,9 @@ ProcXIChangeHierarchy(ClientPtr client)
|
|
rc = add_master(client, c, flags);
|
|
if (rc != Success)
|
|
goto unwind;
|
|
- }
|
|
+ changes = FLUSH;
|
|
break;
|
|
+ }
|
|
case XIRemoveMaster:
|
|
{
|
|
xXIRemoveMasterInfo *r = (xXIRemoveMasterInfo *) any;
|
|
@@ -475,8 +481,9 @@ ProcXIChangeHierarchy(ClientPtr client)
|
|
rc = remove_master(client, r, flags);
|
|
if (rc != Success)
|
|
goto unwind;
|
|
- }
|
|
+ changes = FLUSH;
|
|
break;
|
|
+ }
|
|
case XIDetachSlave:
|
|
{
|
|
xXIDetachSlaveInfo *c = (xXIDetachSlaveInfo *) any;
|
|
@@ -485,8 +492,9 @@ ProcXIChangeHierarchy(ClientPtr client)
|
|
rc = detach_slave(client, c, flags);
|
|
if (rc != Success)
|
|
goto unwind;
|
|
- }
|
|
+ changes = CHANGED;
|
|
break;
|
|
+ }
|
|
case XIAttachSlave:
|
|
{
|
|
xXIAttachSlaveInfo *c = (xXIAttachSlaveInfo *) any;
|
|
@@ -495,16 +503,25 @@ ProcXIChangeHierarchy(ClientPtr client)
|
|
rc = attach_slave(client, c, flags);
|
|
if (rc != Success)
|
|
goto unwind;
|
|
+ changes = CHANGED;
|
|
+ break;
|
|
}
|
|
+ default:
|
|
break;
|
|
}
|
|
|
|
+ if (changes == FLUSH) {
|
|
+ XISendDeviceHierarchyEvent(flags);
|
|
+ memset(flags, 0, sizeof(flags));
|
|
+ changes = NO_CHANGE;
|
|
+ }
|
|
+
|
|
len -= any->length * 4;
|
|
any = (xXIAnyHierarchyChangeInfo *) ((char *) any + any->length * 4);
|
|
}
|
|
|
|
unwind:
|
|
-
|
|
- XISendDeviceHierarchyEvent(flags);
|
|
+ if (changes != NO_CHANGE)
|
|
+ XISendDeviceHierarchyEvent(flags);
|
|
return rc;
|
|
}
|
|
--
|
|
2.43.0
|
|
|