- Apr 03, 2024
-
-
Povilas Kanapickas authored
Signed-off-by:
Povilas Kanapickas <povilas@radix.lt>
-
Previously, AllocateGlyph would return a new glyph with refcount=0 and a re-used glyph would end up not changing the refcount at all. The resulting glyph_new array would thus have multiple entries pointing to the same non-refcounted glyphs. AddGlyph may free a glyph, resulting in a UAF when the same glyph pointer is then later used. Fix this by returning a refcount of 1 for a new glyph and always incrementing the refcount for a re-used glyph, followed by dropping that refcount back down again when we're done with it. CVE-2024-31083, ZDI-CAN-22880 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Part-of: <!1463> (cherry picked from commit bdca6c3d)
-
CVE-2024-31082 Fixes: 14205ade ("XQuartz: appledri: Fix byte swapping in replies") Signed-off-by:
Alan Coopersmith <alan.coopersmith@oracle.com> Part-of: <!1463> (cherry picked from commit 6c684d03)
-
CVE-2024-31081 Fixes: d220d690 ("Xi: add GrabButton and GrabKeysym code.") Signed-off-by:
Alan Coopersmith <alan.coopersmith@oracle.com> Part-of: <!1463> (cherry picked from commit 3e77295f)
-
CVE-2024-31080 Reported-by: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69762 Fixes: 53e821ab ("Xi: add request processing for XIGetSelectedEvents.") Signed-off-by:
Alan Coopersmith <alan.coopersmith@oracle.com> Part-of: <!1463> (cherry picked from commit 96798fc1)
-
- Mar 27, 2024
-
-
Otherwise it causes the server to return BadDrawable giving a byte-swapped resource id instead of the real id the client sent. Reported-by: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69762 Fixes: 397dfd9f ("Create/Destroy/Trigger/Reset/Query Fence Sync objs") Signed-off-by:
Alan Coopersmith <alan.coopersmith@oracle.com> --- (cherry picked from commit e6573baa) Part-of: <!1438>
-
- Mar 23, 2024
-
-
The X server swapping code is a huge attack surface, much of this code is untested and prone to security issues. The use-case of byte-swapped clients is very niche, so allow users to disable this if they don't need it, using either a config option or commandline flag. For Xorg, this adds the ServerFlag "AllowByteSwappedClients" "off". For all DDX, this adds the commandline options +byteswappedclients and -byteswappedclients to enable or disable, respectively. Fixes #1201 Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> --- (cherry picked from commit 41277766) (cherry picked from commit af5cd5ac) Backport to server-21.1-branch modified to keep byte-swapping enabled by default but easy to disable by users or admins (or even by distros shipping an xorg.conf.d fragment in their packages). Signed-off-by:
Alan Coopersmith <alan.coopersmith@oracle.com> Part-of: <!1440>
-
- Feb 23, 2024
-
-
This was overlooked when converting the function to use libxcvt. Bring back name initialization from old code. This was causing a segfault in xf86LookupMode() if modes where name is NULL are present the modePool list. Signed-off-by:
Matthieu Herrb <matthieu@herrb.eu> --- (cherry picked from ed11c4d4) Reported-by:
"Sergiy" <Black_N@ukr.net> Part-of: <xorg/xserver!1319>
-
- Feb 19, 2024
-
-
Potentially, the pointer to the mode name could be unset, this can occur with the xf86-video-nv DDX, in that case there isnt much we can do except check if the next mode is any better. Signed-off-by:
Yusuf Khan <yusisamerican@gmail.com> --- (cherry picked from db3aa4e0) Part-of: <xorg/xserver!1309>
-
- Jan 22, 2024
-
-
This fixes access to freed heap memory via dev->master. E.g. when running BarrierNotify.ReceivesNotifyEvents/7 test from xorg-integration-tests: ==24736==ERROR: AddressSanitizer: heap-use-after-free on address 0x619000065020 at pc 0x55c450e2b9cf bp 0x7fffc532fd20 sp 0x7fffc532fd10 READ of size 4 at 0x619000065020 thread T0 #0 0x55c450e2b9ce in GetMaster ../../../dix/devices.c:2722 #1 0x55c450e9d035 in IsFloating ../../../dix/events.c:346 #2 0x55c4513209c6 in GetDeviceUse ../../../Xi/xiquerydevice.c:525 ../../../Xi/xichangehierarchy.c:95 #4 0x55c450e3455c in RemoveDevice ../../../dix/devices.c:1204 ../../../hw/xfree86/common/xf86Xinput.c:1142 #6 0x55c450e17b04 in CloseDeviceList ../../../dix/devices.c:1038 #7 0x55c450e1de85 in CloseDownDevices ../../../dix/devices.c:1068 #8 0x55c450e837ef in dix_main ../../../dix/main.c:302 #9 0x55c4517a8d93 in main ../../../dix/stubmain.c:34 (/lib/x86_64-linux-gnu/libc.so.6+0x28564) #11 0x55c450d0113d in _start (/usr/lib/xorg/Xorg+0x117713d) 0x619000065020 is located 160 bytes inside of 912-byte region [0x619000064f80,0x619000065310) freed by thread T0 here: (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10d7cf) #1 0x55c450e19f1c in CloseDevice ../../../dix/devices.c:1014 #2 0x55c450e343a4 in RemoveDevice ../../../dix/devices.c:1186 ../../../hw/xfree86/common/xf86Xinput.c:1142 #4 0x55c450e17b04 in CloseDeviceList ../../../dix/devices.c:1038 #5 0x55c450e1de85 in CloseDownDevices ../../../dix/devices.c:1068 #6 0x55c450e837ef in dix_main ../../../dix/main.c:302 #7 0x55c4517a8d93 in main ../../../dix/stubmain.c:34 (/lib/x86_64-linux-gnu/libc.so.6+0x28564) previously allocated by thread T0 here: (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6) #1 0x55c450e1c57b in AddInputDevice ../../../dix/devices.c:259 #2 0x55c450e34840 in AllocDevicePair ../../../dix/devices.c:2755 #3 0x55c45130318f in add_master ../../../Xi/xichangehierarchy.c:152 ../../../Xi/xichangehierarchy.c:465 #5 0x55c4512cb9f5 in ProcIDispatch ../../../Xi/extinit.c:390 #6 0x55c450e6a92b in Dispatch ../../../dix/dispatch.c:551 #7 0x55c450e834b7 in dix_main ../../../dix/main.c:272 #8 0x55c4517a8d93 in main ../../../dix/stubmain.c:34 (/lib/x86_64-linux-gnu/libc.so.6+0x28564) The problem is caused by dev->master being not reset when disabling the device, which then causes dangling pointer when the master device itself is being deleted when exiting whole server. Note that RecalculateMasterButtons() requires dev->master to be still valid, so we can reset it only at the end of function. Signed-off-by:
Povilas Kanapickas <povilas@radix.lt> (cherry picked from commit 1801fe0a)
-
- Jan 16, 2024
-
-
José Expósito authored
Signed-off-by:
José Expósito <jose.exposito89@gmail.com>
-
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 2ef0f111)
-
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 e5e8586a)
-
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 26769aa7)
-
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 bc1fdbe4)
-
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 4a5e9b18)
-
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 df3c6570)
-
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 219c54b8)
-
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 ece23be8)
-
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 9e2ecb2a)
-
- Jan 03, 2024
-
-
Michael Wyraz authored
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.
-
- 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)
-