commit 31407c0199da877b359b2e37bb371804321279b7
Author: José Expósito <jose.exposito89@gmail.com>
Date:   Tue Jan 16 10:15:15 2024 +0100

    xserver 21.1.11
    
    Signed-off-by: José Expósito <jose.exposito89@gmail.com>

commit a4f0e9466f3bc7073a8f0c28a581211c2d7adf0e
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Wed Dec 6 11:51:56 2023 +0100

    ephyr,xwayland: Use the proper private key for cursor
    
    The cursor in DIX is actually split in two parts, the cursor itself and
    the cursor bits, each with their own devPrivates.
    
    The cursor itself includes the cursor bits, meaning that the cursor bits
    devPrivates in within structure of the cursor.
    
    Both Xephyr and Xwayland were using the private key for the cursor bits
    to store the data for the cursor, and when using XSELINUX which comes
    with its own special devPrivates, the data stored in that cursor bits'
    devPrivates would interfere with the XSELINUX devPrivates data and the
    SELINUX security ID would point to some other unrelated data, causing a
    crash in the XSELINUX code when trying to (re)use the security ID.
    
    CVE-2024-0409
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit 2ef0f1116c65d5cb06d7b6d83f8a1aea702c94f7)

commit 8d825f72da71d6c38cbb02cf2ee2dd9e0e0f50f2
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Wed Dec 6 12:09:41 2023 +0100

    glx: Call XACE hooks on the GLX buffer
    
    The XSELINUX code will label resources at creation by checking the
    access mode. When the access mode is DixCreateAccess, it will call the
    function to label the new resource SELinuxLabelResource().
    
    However, GLX buffers do not go through the XACE hooks when created,
    hence leaving the resource actually unlabeled.
    
    When, later, the client tries to create another resource using that
    drawable (like a GC for example), the XSELINUX code would try to use
    the security ID of that object which has never been labeled, get a NULL
    pointer and crash when checking whether the requested permissions are
    granted for subject security ID.
    
    To avoid the issue, make sure to call the XACE hooks when creating the
    GLX buffers.
    
    Credit goes to Donn Seeley <donn@xmission.com> for providing the patch.
    
    CVE-2024-0408
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit e5e8586a12a3ec915673edffa10dc8fe5e15dac3)

commit 5c4816afa7722ea47d1a7dea983a953e7b454d26
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Jan 5 09:40:27 2024 +1000

    dix: when disabling a master, float disabled slaved devices too
    
    Disabling a master device floats all slave devices but we didn't do this
    to already-disabled slave devices. As a result those devices kept their
    reference to the master device resulting in access to already freed
    memory if the master device was removed before the corresponding slave
    device.
    
    And to match this behavior, also forcibly reset that pointer during
    CloseDownDevices().
    
    Related to CVE-2024-21886, ZDI-CAN-22840
    
    (cherry picked from commit 26769aa71fcbe0a8403b7fb13b7c9010cc07c3a8)

commit 7b5694368b3f3b039fb523e66b816c1323f3cc39
Author: José Expósito <jexposit@redhat.com>
Date:   Fri Dec 22 18:28:31 2023 +0100

    Xi: do not keep linked list pointer during recursion
    
    The `DisableDevice()` function is called whenever an enabled device
    is disabled and it moves the device from the `inputInfo.devices` linked
    list to the `inputInfo.off_devices` linked list.
    
    However, its link/unlink operation has an issue during the recursive
    call to `DisableDevice()` due to the `prev` pointer pointing to a
    removed device.
    
    This issue leads to a length mismatch between the total number of
    devices and the number of device in the list, leading to a heap
    overflow and, possibly, to local privilege escalation.
    
    Simplify the code that checked whether the device passed to
    `DisableDevice()` was in `inputInfo.devices` or not and find the
    previous device after the recursion.
    
    CVE-2024-21886, ZDI-CAN-22840
    
    This vulnerability was discovered by:
    Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
    
    (cherry picked from commit bc1fdbe46559dd947674375946bbef54dd0ce36b)

commit 6236342157b9ddc9a4ebb3438e469a8cb37eaecb
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Jan 4 10:01:24 2024 +1000

    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)

commit 8887cb1f27c72324b50383b644cefb960e21f5ff
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Dec 21 13:48:10 2023 +1000

    Xi: when creating a new ButtonClass, set the number of buttons
    
    There's a racy sequence where a master device may copy the button class
    from the slave, without ever initializing numButtons. This leads to a
    device with zero buttons but a button class which is invalid.
    
    Let's copy the numButtons value from the source - by definition if we
    don't have a button class yet we do not have any other slave devices
    with more than this number of buttons anyway.
    
    CVE-2024-0229, ZDI-CAN-22678
    
    This vulnerability was discovered by:
    Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
    
    (cherry picked from commit df3c65706eb169d5938df0052059f3e0d5981b74)

commit 7173a8911ebeaa7c9c12bd64a2ba9c8685c6593c
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Dec 18 12:26:20 2023 +1000

    dix: fix DeviceStateNotify event calculation
    
    The previous code only made sense if one considers buttons and keys to
    be mutually exclusive on a device. That is not necessarily true, causing
    a number of issues.
    
    This function allocates and fills in the number of xEvents we need to
    send the device state down the wire.  This is split across multiple
    32-byte devices including one deviceStateNotify event and optional
    deviceKeyStateNotify, deviceButtonStateNotify and (possibly multiple)
    deviceValuator events.
    
    The previous behavior would instead compose a sequence
    of [state, buttonstate, state, keystate, valuator...]. This is not
    protocol correct, and on top of that made the code extremely convoluted.
    
    Fix this by streamlining: add both button and key into the deviceStateNotify
    and then append the key state and button state, followed by the
    valuators. Finally, the deviceValuator events contain up to 6 valuators
    per event but we only ever sent through 3 at a time. Let's double that
    troughput.
    
    CVE-2024-0229, ZDI-CAN-22678
    
    This vulnerability was discovered by:
    Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
    
    (cherry picked from commit 219c54b8a3337456ce5270ded6a67bcde53553d5)

commit c494debaa76c923621e6b9f54bbd59ed47842b30
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Dec 18 14:27:50 2023 +1000

    dix: Allocate sufficient xEvents for our DeviceStateNotify
    
    If a device has both a button class and a key class and numButtons is
    zero, we can get an OOB write due to event under-allocation.
    
    This function seems to assume a device has either keys or buttons, not
    both. It has two virtually identical code paths, both of which assume
    they're applying to the first event in the sequence.
    
    A device with both a key and button class triggered a logic bug - only
    one xEvent was allocated but the deviceStateNotify pointer was pushed on
    once per type. So effectively this logic code:
    
       int count = 1;
       if (button && nbuttons > 32) count++;
       if (key && nbuttons > 0) count++;
       if (key && nkeys > 32) count++; // this is basically always true
       // count is at 2 for our keys + zero button device
    
       ev = alloc(count * sizeof(xEvent));
       FixDeviceStateNotify(ev);
       if (button)
         FixDeviceStateNotify(ev++);
       if (key)
         FixDeviceStateNotify(ev++);   // santa drops into the wrong chimney here
    
    If the device has more than 3 valuators, the OOB is pushed back - we're
    off by one so it will happen when the last deviceValuator event is
    written instead.
    
    Fix this by allocating the maximum number of events we may allocate.
    Note that the current behavior is not protocol-correct anyway, this
    patch fixes only the allocation issue.
    
    Note that this issue does not trigger if the device has at least one
    button. While the server does not prevent a button class with zero
    buttons, it is very unlikely.
    
    CVE-2024-0229, ZDI-CAN-22678
    
    This vulnerability was discovered by:
    Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
    
    (cherry picked from commit ece23be888a93b741aa1209d1dbf64636109d6a5)

commit 4e78bc3a6e593f70aa5306b314edbec03d2f9081
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Dec 14 11:29:49 2023 +1000

    dix: allocate enough space for logical button maps
    
    Both DeviceFocusEvent and the XIQueryPointer reply contain a bit for
    each logical button currently down. Since buttons can be arbitrarily mapped
    to anything up to 255 make sure we have enough bits for the maximum mapping.
    
    CVE-2023-6816, ZDI-CAN-22664, ZDI-CAN-22665
    
    This vulnerability was discovered by:
    Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
    
    (cherry picked from commit 9e2ecb2af8302dedc49cb6a63ebe063c58a9e7e3)

commit c338d19f743ca5872ff74d6f2ce5d37d3b7f4a2a
Author: Michael Wyraz <mw@brick4u.de>
Date:   Fri Oct 14 15:07:27 2022 +0200

    Removing the code that deletes an existing monitor in RRMonitorAdd
    
    In commit 7e1f86d4 monitor support was added to randr. At this time it seemed to be reasonable not to have
    more than one (virtual) monitor on a particular physical display. The code was never changed since.
    
    Nowadays, extremely large displays exists (4k displays, ultra-wide displays). In some use cases it makes sense to
    split these large physical displays into multiple virtual monitors. An example are ultra-wide screens that can be
    split into 2 monitors. The change in this commit makes this work.
    
    Besides that, removing a monitor in a function that is called "RRMonitorAdd" is bad practice and causes
    unexpected behaviour.

commit 15e2409776014b41c77f7da7aeb9520613994d27
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Dec 13 11:12:59 2023 +1000

    xserver 21.1.10
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

commit a7bda3080d2b44eae668cdcec7a93095385b9652
Author: Peter Hutterer <peter.hutterer@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)

commit 58e83c683950ac9e253ab05dd7a13a8368b70a3c
Author: Peter Hutterer <peter.hutterer@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@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)

commit c1ad8df2fc570c482af832681260864b98c47791
Author: nerdopolis <bluescreen_avenger@verizon.net>
Date:   Tue Jan 11 18:41:42 2022 -0500

    xephyr: Don't check for SeatId anymore
    
    After a change for the xserver to automatically determine the seat
    based on the XDG_SEAT variable, xephyr stopped working. This was
    because of an old feature where xephyr used to handle evdev
    directly. This was dropped some time ago, and now this check is
    not needed
    
    (cherry picked from commit 4c03b67d334b05b814239420776f2fdd4c4a98ac)

commit 6197bea02eec072c19aa5365962e89949e674099
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Oct 25 11:05:28 2023 +1000

    xserver 21.1.9
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

commit 3e290b3c7c3018acf1f08979d014fe3941c94f84
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Oct 5 12:19:45 2023 +1000

    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>
    (cherry picked from commit 564ccf2ce9616620456102727acb8b0256b7bbd7)

commit f2922f6ffa871b0d549878303ca09bc53cdadcf8
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Oct 3 11:53:05 2023 +1000

    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>
    (cherry picked from commit 541ab2ecd41d4d8689e71855d93e492bc554719a)

commit 2c33ee9f1d6da648a5176795608eb3138ef46e49
Author: Sam James <sam@gentoo.org>
Date:   Wed Aug 2 12:33:19 2023 +0100

    Switch to libbsd-overlay
    
    This is more portable than libbsd as everything Just Works, even on BSD systems,
    and is the recommended method of consuming libbsd nowadays.
    
    It also helpfully lets things work with glibc-provided functions for new
    enough glibc.
    
    [For the 21.1.x backport, take inspiration from @alanc's commit to libxdmcp
    at https://gitlab.freedesktop.org/xorg/lib/libxdmcp/-/commit/c01da8ebd0969efd15388ce999e121127cc46f67.]
    
    Closes: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/973
    Co-authored-by: Guillem Jover <guillem@hadrons.org>
    (cherry picked from commit 94945a52746ee2612c6cd394692f49e2ed5fc56b)
    Signed-off-by: Sam James <sam@gentoo.org>

commit b98fc07d3442a289c6bef82df50dd0a2d01de71a
Author: Adam Jackson <ajax@redhat.com>
Date:   Thu Feb 2 12:26:27 2023 -0500

    present: Send a PresentConfigureNotify event for destroyed windows
    
    This enables fixing a deadlock case on the client side, where the client
    ends up blocked waiting for a Present event that will never come because
    the window was destroyed. The new PresentWindowDestroyed flag allows the
    client to avoid blocking indefinitely.
    
    Signed-off-by: Adam Jackson <ajax@redhat.com>
    See-also: https://gitlab.freedesktop.org/mesa/mesa/-/issues/116
    See-also: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6685
    Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
    (cherry picked from commit 462b06033e66a32308d940eb5fc47f5e4c914dc0)

commit 7c791b15504cc86a929acaa88161f012cdbba59f
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Wed Mar 29 13:58:30 2023 +0200

    xserver 21.1.8
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>

commit fb51d5dd53b02422ea3b6f36bd017488d41f472d
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Mar 13 11:08:47 2023 +0100

    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>
    (cherry picked from commit 26ef545b3502f61ca722a7a3373507e88ef64110)

commit 6bed5cfd515b9634ecf73fb884e4ec3388e8b7eb
Author: Benno Schulenberg <bensberg@telfort.nl>
Date:   Mon Mar 27 20:03:56 2023 +0200

    xkbUtils: use existing symbol names instead of deleted deprecated ones
    
    Symbols `XK_Cyrillic_DZHE` and `XK_Serbian_DZE` were pure synonyms.
    
    (cherry picked from commit 6153c71cfb4698f1a416266564ecc748e4a25f2c)

commit af9111ac7fa399a5a33fbfa145060e1850f41e0e
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Feb 7 10:30:37 2023 +1000

    xserver 21.1.7
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

commit 9ca7d3f61a88ae6cf47fdf139b6215d745db976b
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Jan 25 11:41:40 2023 +1000

    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>
    (cherry picked from commit 0ba6d8c37071131a49790243cdac55392ecf71ec)

commit 4b925d388f76764dcb02dfd1cd7276262dcd7d74
Author: Mike Gorse <mgorse@suse.com>
Date:   Wed Jan 25 02:02:48 2023 +0000

    dix: Use CopyPartialInternalEvent in EnqueueEvent
    
    The event might be a DeviceEvent allocated on the stack, in
    AccessXKeyboardEvent for instance. Fixes out-of-bounds read.
    
    Signed-off-by: Mike Gorse <mgorse@suse.com>
    (cherry picked from commit 2ef5ef57bd37a8bec2ac454053b283c6f87c3b40)

commit 44d6c82ac82a78d904a6d47387ac363d9699b891
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Wed Jan 18 10:38:41 2023 -0800

    darwin: Implement DetermineClientCmd for macOS
    
    Withoug a proper implementation of DetermineClientCmd, clients that
    connect via an ssh tunnel are miscategorized as local.  This results
    in failures when we try to use SCM_RIGHTS (eg: in MIT-SHM).
    
    Fixes: https://github.com/XQuartz/XQuartz/issues/314
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit 0ea9b595891f2f31915538192961f3404d9ca699)

commit 1317083fbc407dc9dbb04ba5b98187b75222a16f
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Wed Jan 18 12:19:05 2023 -0800

    os: Use LOCAL_PEERPID from sys/un.h if it is available to detemine the pid when falling back on getpeereids()
    
    This provides a way to determine the pid of a peer connection on
    systems like darwin that do not support getpeerucred() nor
    SO_PEERCRED.
    
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit 8a4ab2287398773a4868c220662d93bf84ec6241)

commit a6c49106cef36e84eb11d64e325465250b7678be
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Wed Jan 18 12:02:54 2023 -0800

    os: Update GetLocalClientCreds to prefer getpeerucred() or SO_PEERCRED over getpeereid()
    
    GetLocalClientCreds() was preferring getpeereid() above other implementations.
    
    getpeereid(), however, only returns the effective uid and gid of the peer,
    leaving the pid unset.  When this happens, we are unable to use the pid to
    determine the peer's command line arguments and incorrectly treat ssh-tunneled
    traffic as local.
    
    To address this, we now prioritize getpeerucred() or SO_PEERCRED as those two
    implementations will return the pid in addition to uid and gid.
    
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit 165d5c1260edcb998c5cf31d3969723c7452aa7f)

commit a220f53cb81248d06fb6f044c102c6ab8bffe2d5
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Wed Jan 18 10:44:27 2023 -0800

    os: Update AllocNewConnection() debug logging to include whether or not the client is local
    
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit 2577291f010e07173d0fc8b310ac355928f8ed7d)

commit 07f9689507eee11bdbc2828ac1319fbde91ad27c
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Sun Nov 27 22:25:49 2022 -0800

    Revert "meson: Don't build COMPOSITE for XQuartz"
    
    This will allow us to remove build-time conditionalization on COMPOSITE
    while still allowing XQuartz to disable it and use ROOTLESS.
    
    This reverts commit 5f2d652377995c0c0c3cf07463b5018450661d13
    
    (cherry picked from commit 66e7b7349dffda6fef51ed029fdc91b787ca4c08)

commit 8ea43dd8bf8f8f2cb82a2a1f2c004ee873e7810d
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Sun Nov 27 22:23:43 2022 -0800

    xquartz: Disable COMPOSITE at runtime
    
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit 2567388a2957cef526df1b7efb2684aa74feb641)

commit aa0d8d440c39beb276cd26723d822728ce394e01
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Tue Jan 17 07:33:19 2023 -0800

    xquartz: Update the about box copyright to 2023
    
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit 15077090d371a2679d274c5d129a3102762d18ec)

commit 8feba178f8b73b983033c197c384c580a6397a41
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Sat Jan 14 23:33:59 2023 -0800

    xquartz: Fix building with autoconf
    
    Regressed-in: 5d302c378d9d21b34db2434425b766ac4f05de89
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>

commit c8ef9e38187e00dbaf956893f987e15e8f42f61c
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jul 12 14:44:48 2022 +0200

    dix: Fix overzealous caching of ResourceClientBits()
    
    Commit c7311654 cached the value of ResourceClientBits(), but that value
    depends on the `MaxClients` value set either from the command line or
    from the configuration file.
    
    For the latter, a call to ResourceClientBits() is issued before the
    configuration file is read, meaning that the cached value is from the
    default, not from the maximum number of clients set in the configuration
    file.
    
    That obviously causes all sort of issues, including memory corruption
    and crashes of the Xserver when reaching the default limit value.
    
    To avoid that issue, also keep the LimitClient value, and recompute the
    ilog2() value if that changes, as on startup when the value is set from
    the the xorg.conf ServerFlags section.
    
    v2: Drop the `cache == 0` test
        Rename cache vars
    
    Fixes: c7311654 - dix: cache ResourceClientBits() value
    Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1310
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Adam Jackson <ajax@redhat.com>
    (cherry picked from commit 2efa6d659508346358a1ef27b2393e18843f66a3)

commit a0216de2367429788be4ef430026ada215106ff5
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Wed Dec 14 23:45:13 2022 -0800

    rootless: Add additional debug logging to help triage XQuartz fb/rootless/damage crashes
    
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit 07ed1a623a4b36cdb741a322008ba53d913dc765)

commit 264272f3d76e4f1e50d984640c57de77aca9ba37
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Wed Dec 14 17:07:46 2022 -0800

    xquartz: Use xorg_backtrace() instead of rolling our own for debugging
    
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit d1a9a50792110683ae3f993eeeffeee79cf9cbce)

commit 20f380c6d93be3ef561251584163d1fe1ae2d966
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Wed Dec 21 01:18:11 2022 -0800

    xquartz: Ignore SIGPIPE at process launch
    
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit 9a66690eaf67c19b90e07f39b16436d34b59e27a)

commit 59b6fc88ed9f4b22397a568c2483e4c558856ffa
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Dec 19 10:46:20 2022 +0100

    xserver 21.1.6
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>

commit b7760d41c177983c2f2fca2ebdb8105628291720
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Dec 19 10:06:45 2022 +1000

    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 <peter.hutterer@who-t.net>
    (cherry picked from commit bb1711b7fba42f2a0c7d1c09beee241a1b2bcc30)

commit 69ab3bcaa0f6a5adef6ec19161eb856a4744b32c
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Jul 13 11:23:09 2022 +1000

    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>
    (cherry picked from commit 18f91b950e22c2a342a4fbc55e9ddf7534a707d2)

commit 5dbb2b52cfeab212b5c9b7e344692a6384efdc4c
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Jul 5 12:06:20 2022 +1000

    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>
    (cherry picked from commit 11beef0b7f1ed290348e45618e5fa0d2bffcb72e)

commit becf9d51c33a21e7700b18bb2324f466bb966de5
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Wed Dec 14 00:13:34 2022 -0800

    xquartz: Fix some formatting
    
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>

commit 61d18bed664769b1d94ea1320e27f71560a01af2
Author: John D Pell <John+git@gaelicWizard.net>
Date:   Tue Jul 13 23:46:28 2021 -0700

    XQuartz: stub: Call LSOpenApplication instead of fork()/exec()
    
    Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>

commit f292fbfaac0c653ee49bbb24deb3add2b5da602f
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Dec 14 11:34:41 2022 +1000

    xserver 21.1.5
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

commit e860bbce4fdb169e84033529331ae2666e679de7
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Dec 5 15:55:54 2022 +1000

    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>
    (cherry picked from commit ccdd431cd8f1cabae9d744f0514b6533c438908c)

commit 8a1fa008b2f90abce6cabb27d9bc2ed76d07b678
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Nov 29 13:26:57 2022 +1000

    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>
    (cherry picked from commit 8f454b793e1f13c99872c15f0eed1d7f3b823fe8)

commit 40f431de8a76f737c68ae659fee8472583f15e49
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Nov 29 13:24:00 2022 +1000

    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>
    (cherry picked from commit b8a84cb0f2807b07ab70ca9915fcdee21301b8ca)

commit d6c7de9eadca980c8ce3b3b7752b67bfa95e6f31
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Nov 29 14:53:07 2022 +1000

    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>
    (cherry picked from commit 842ca3ccef100ce010d1d8f5f6d6cc1915055900)

commit 67927cc41f452228188bbe2aa34a9ee4a9ce0c6b
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Nov 30 11:20:40 2022 +1000

    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>
    (cherry picked from commit b79f32b57cc0c1186b2899bce7cf89f7b325161b)

commit a6c0d7b142e762a6b9934a23e060ea91ff5afcea
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Nov 29 13:55:32 2022 +1000

    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>
    (cherry picked from commit 51eb63b0ee1509c6c6b8922b0e4aa037faa6f78b)

commit 936d34bdff4c479ccd0405fc221ff8e4c6c7014d
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Nov 29 12:55:45 2022 +1000

    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>
    (cherry picked from commit b320ca0ffe4c0c872eeb3a93d9bde21f765c7c63)

commit 5f2d652377995c0c0c3cf07463b5018450661d13
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Sun Nov 27 15:04:13 2022 -0800

    meson: Don't build COMPOSITE for XQuartz
    
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit 9c0373366988cc0b909ba31e61c43cc46e054b40)

commit 3dee0aac2c0ed4538880b65ee528e4633d103592
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Thu Nov 24 10:58:26 2022 -0800

    xquartz: Move default applications list outside of the main executable
    
    This will allow side-wide customization.
    
    Fixes: https://github.com/XQuartz/XQuartz/issues/274
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit e654de80ed560c480efc072d876808b1d78da052)

commit 5d302c378d9d21b34db2434425b766ac4f05de89
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Thu Nov 24 11:04:08 2022 -0800

    xquartz: Remove unused macro (X11LIBDIR)
    
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit 3dbd809c0e2d8da4191dd4a3fd4abdd14be0d838)

commit 6bf62381d0a1fb54226a10f9d0e6b03aff12f3aa
Author: Povilas Kanapickas <povilas@radix.lt>
Date:   Tue Jul 12 16:09:23 2022 +0300

    xserver 21.1.4
