- Dec 13, 2023
-
-
Peter Hutterer authored
Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
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 0c1a93d3)
-
Peter Hutterer authored
Affected are ProcRRChangeProviderProperty and ProcRRChangeOutputProperty. See also 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 14f48001)
-
- Oct 25, 2023
-
-
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 4c03b67d)
-
Peter Hutterer authored
Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
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 564ccf2c)
-
Peter Hutterer authored
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 541ab2ec)
-
- Oct 24, 2023
-
-
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 xorg/lib/libxdmcp@c01da8eb.] Closes: !973 Co-authored-by:
Guillem Jover <guillem@hadrons.org> (cherry picked from commit 94945a52) Signed-off-by:
Sam James <sam@gentoo.org>
-
- Apr 24, 2023
-
-
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: mesa/mesa#116 See-also: mesa/mesa#6685 Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 462b0603)
-
- Mar 29, 2023
-
-
Olivier Fourdan authored
Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com>
-
Olivier Fourdan authored
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 26ef545b)
-
Symbols `XK_Cyrillic_DZHE` and `XK_Serbian_DZE` were pure synonyms. (cherry picked from commit 6153c71c)
-
- Feb 07, 2023
-
-
Peter Hutterer authored
Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
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 0ba6d8c3)
-
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 2ef5ef57)
-
- Jan 26, 2023
-
-
Jeremy Huddleston Sequoia authored
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 0ea9b595)
-
Jeremy Huddleston Sequoia authored
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 8a4ab228)
-
Jeremy Huddleston Sequoia authored
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 165d5c12)
-
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com> (cherry picked from commit 2577291f)
-
- Jan 17, 2023
-
-
Jeremy Huddleston Sequoia authored
This will allow us to remove build-time conditionalization on COMPOSITE while still allowing XQuartz to disable it and use ROOTLESS. This reverts commit 5f2d6523 (cherry picked from commit 66e7b734)
-
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com> (cherry picked from commit 2567388a)
-
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com> (cherry picked from commit 15077090)
-
- Jan 15, 2023
-
-
Jeremy Huddleston Sequoia authored
Regressed-in: 5d302c37 Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
-
- Jan 11, 2023
-
-
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: #1310 Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Adam Jackson <ajax@redhat.com> (cherry picked from commit 2efa6d65)
-
- Dec 21, 2022
-
-
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com> (cherry picked from commit 07ed1a62)
-
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com> (cherry picked from commit d1a9a507)
-
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com> (cherry picked from commit 9a66690e)
-
- Dec 19, 2022
-
-
Olivier Fourdan authored
Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com>
-
Peter Hutterer authored
In commit b320ca0f the mask was inadvertently changed from octal 0177 to hexadecimal 0x177. Fixes commit b320ca0f Xtest: disallow GenericEvents in XTestSwapFakeInput Found by Stuart Cassoff Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit bb1711b7)
-
- Dec 14, 2022
-
-
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 18f91b95)
-
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 11beef0b)
-
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
-
Reviewed-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
-
Peter Hutterer authored
Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
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 ccdd431c)
-
Peter Hutterer authored
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 8f454b79)
-
Peter Hutterer authored
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 b8a84cb0)
-
Peter Hutterer authored
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 842ca3cc)
-
Peter Hutterer authored
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 b79f32b5)
-
Peter Hutterer authored
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 51eb63b0)
-