There is 1 open security issue in trixie.
There is 1 open security issue in sid.
commit b6acc2e6eb9f4bf97e7fc4b4da3ef3d9489267e4 Author: Chris Hofstaedtler <zeha@debian.org> Date: Fri Dec 15 00:00:31 2023 +0100 Use udev.pc to place udev files Closes: #1057945 commit f39efc296cebdcbe0640a077d3ab9fa3ccef1107 Author: Julien Cristau <jcristau@debian.org> Date: Mon Jan 22 13:17:18 2024 +0100 Upload to unstable commit 99e7aaca0313f3e072b83a7e97fad492d687244d Author: Salvatore Bonaccorso <carnil@debian.org> Date: Mon Jan 22 07:49:28 2024 +0100 dix: Fix use after free in input device shutdown Closes: #1061110 commit 5783b1d41d9d63d5dd8f28f25a24f0a176530922 Author: Julien Cristau <jcristau@debian.org> Date: Tue Jan 16 15:33:57 2024 +0100 Add changelog entry commit f3afc1fdc068f4e8ee31677470ac49ebe33be4e9 Merge: 8db596f 31407c0 Author: Julien Cristau <jcristau@debian.org> Date: Tue Jan 16 15:21:19 2024 +0100 Merge tag 'xorg-server-21.1.11' into debian-unstable xorg-server-21.1.11 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.
There is 1 open security issue in bullseye.
You can find information about how to handle this issue in the security team's documentation.
There is 1 open security issue in bookworm.
You can find information about how to handle this issue in the security team's documentation.