xserver: Branch 'xwayland-23.2' - 2 commits

[GitLab Mirror]

 Xi/exevents.c              |   12 ++++++------
 dix/devices.c              |   10 ++++++++++
 randr/rrproperty.c         |    2 +-
 randr/rrproviderproperty.c |    2 +-
 4 files changed, 18 insertions(+), 8 deletions(-)

New commits:
commit 19e9f199950aaa4b9b7696936d1b067475da999c
Author: Peter Hutterer <peter.hutterer at who-t.net>
Date:   Tue Nov 28 15:19:04 2023 +1000

    Xi: allocate enough XkbActions for our buttons
    
    button->xkb_acts is supposed to be an array sufficiently large for all
    our buttons, not just a single XkbActions struct. Allocating
    insufficient memory here means when we memcpy() later in
    XkbSetDeviceInfo we write into memory that wasn't ours to begin with,
    leading to the usual security ooopsiedaisies.
    
    CVE-2023-6377, ZDI-CAN-22412, ZDI-CAN-22413
    
    This vulnerability was discovered by:
    Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
    
    (cherry picked from commit 0c1a93d319558fe3ab2d94f51d174b4f93810afd)

diff --git a/Xi/exevents.c b/Xi/exevents.c
index dcd4efb3b..54ea11a93 100644
--- a/Xi/exevents.c
+++ b/Xi/exevents.c
@@ -611,13 +611,13 @@ DeepCopyPointerClasses(DeviceIntPtr from, DeviceIntPtr to)
         }
 
         if (from->button->xkb_acts) {
-            if (!to->button->xkb_acts) {
-                to->button->xkb_acts = calloc(1, sizeof(XkbAction));
-                if (!to->button->xkb_acts)
-                    FatalError("[Xi] not enough memory for xkb_acts.\n");
-            }
+            size_t maxbuttons = max(to->button->numButtons, from->button->numButtons);
+            to->button->xkb_acts = xnfreallocarray(to->button->xkb_acts,
+                                                   maxbuttons,
+                                                   sizeof(XkbAction));
+            memset(to->button->xkb_acts, 0, maxbuttons * sizeof(XkbAction));
             memcpy(to->button->xkb_acts, from->button->xkb_acts,
-                   sizeof(XkbAction));
+                   from->button->numButtons * sizeof(XkbAction));
         }
         else {
             free(to->button->xkb_acts);
diff --git a/dix/devices.c b/dix/devices.c
index 7150734a5..20fef1692 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -2530,6 +2530,8 @@ RecalculateMasterButtons(DeviceIntPtr slave)
 
     if (master->button && master->button->numButtons != maxbuttons) {
         int i;
+        int last_num_buttons = master->button->numButtons;
+
         DeviceChangedEvent event = {
             .header = ET_Internal,
             .type = ET_DeviceChanged,
@@ -2540,6 +2542,14 @@ RecalculateMasterButtons(DeviceIntPtr slave)
         };
 
         master->button->numButtons = maxbuttons;
+        if (last_num_buttons < maxbuttons) {
+            master->button->xkb_acts = xnfreallocarray(master->button->xkb_acts,
+                                                       maxbuttons,
+                                                       sizeof(XkbAction));
+            memset(&master->button->xkb_acts[last_num_buttons],
+                   0,
+                   (maxbuttons - last_num_buttons) * sizeof(XkbAction));
+        }
 
         memcpy(&event.buttons.names, master->button->labels, maxbuttons *
                sizeof(Atom));
commit aaf854fb25541380cc38a221c15f0e8372f48872
Author: Peter Hutterer <peter.hutterer at who-t.net>
Date:   Mon Nov 27 16:27:49 2023 +1000

    randr: avoid integer truncation in length check of ProcRRChange*Property
    
    Affected are ProcRRChangeProviderProperty and ProcRRChangeOutputProperty.
    See also xserver at 8f454b79 where this same bug was fixed for the core
    protocol and XI.
    
    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->nUnits 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->nUnits bytes, i.e. 4GB.
    
    CVE-2023-6478, ZDI-CAN-22561
    
    This vulnerability was discovered by:
    Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
    
    (cherry picked from commit 14f480010a93ff962fef66a16412fafff81ad632)

diff --git a/randr/rrproperty.c b/randr/rrproperty.c
index 25469f57b..c4fef8a1f 100644
--- a/randr/rrproperty.c
+++ b/randr/rrproperty.c
@@ -530,7 +530,7 @@ ProcRRChangeOutputProperty(ClientPtr client)
     char format, mode;
     unsigned long len;
     int sizeInBytes;
-    int totalSize;
+    uint64_t totalSize;
     int err;
 
     REQUEST_AT_LEAST_SIZE(xRRChangeOutputPropertyReq);
diff --git a/randr/rrproviderproperty.c b/randr/rrproviderproperty.c
index b79c17f9b..90c5a9a93 100644
--- a/randr/rrproviderproperty.c
+++ b/randr/rrproviderproperty.c
@@ -498,7 +498,7 @@ ProcRRChangeProviderProperty(ClientPtr client)
     char format, mode;
     unsigned long len;
     int sizeInBytes;
-    int totalSize;
+    uint64_t totalSize;
     int err;
 
     REQUEST_AT_LEAST_SIZE(xRRChangeProviderPropertyReq);