fix CVE-2023-6377 CVE-2023-6478 CVE-2023-6816 CVE-2024-0408 CVE-2024-0409

This commit is contained in:
cenhuilin 2024-05-06 17:40:27 +08:00
parent 4c9bd99921
commit 908c551c04
6 changed files with 296 additions and 2 deletions

View File

@ -0,0 +1,75 @@
From 0c1a93d319558fe3ab2d94f51d174b4f93810afd Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Mon, 6 May 2024 16:59:46 +0800
Subject: [PATCH] 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
---
Xi/exevents.c | 12 ++++++------
dix/devices.c | 10 ++++++++++
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/Xi/exevents.c b/Xi/exevents.c
index 94b9983..d627da3 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 5bf956e..4190e2d 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -2525,6 +2525,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,
@@ -2535,6 +2537,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));
--
2.33.0

View File

@ -0,0 +1,58 @@
From 14f480010a93ff962fef66a16412fafff81ad632 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Mon, 6 May 2024 17:10:20 +0800
Subject: [PATCH] randr: avoid integer truncation in length check of ProcRRChange*Property.
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
---
randr/rrproperty.c | 2 +-
randr/rrproviderproperty.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/randr/rrproperty.c b/randr/rrproperty.c
index c2fb958..1fb89e6 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 b79c17f..90c5a9a 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);
--
2.33.0

View File

@ -0,0 +1,51 @@
From 9e2ecb2af8302dedc49cb6a63ebe063c58a9e7e3 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Mon, 6 May 2024 17:15:43 +0800
Subject: [PATCH] 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
---
Xi/xiquerypointer.c | 3 +--
dix/enterleave.c | 5 +++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Xi/xiquerypointer.c b/Xi/xiquerypointer.c
index 5b77b1a..da3afd7 100644
--- a/Xi/xiquerypointer.c
+++ b/Xi/xiquerypointer.c
@@ -149,8 +149,7 @@ ProcXIQueryPointer(ClientPtr client)
if (pDev->button) {
int i;
- rep.buttons_len =
- bytes_to_int32(bits_to_bytes(pDev->button->numButtons));
+ rep.buttons_len = bytes_to_int32(bits_to_bytes(256)); /* button map up to 255 */
rep.length += rep.buttons_len;
buttons = calloc(rep.buttons_len, 4);
if (!buttons)
diff --git a/dix/enterleave.c b/dix/enterleave.c
index 033ddc2..766f5c8 100644
--- a/dix/enterleave.c
+++ b/dix/enterleave.c
@@ -784,8 +784,9 @@ DeviceFocusEvent(DeviceIntPtr dev, int type, int mode, int detail,
mouse = IsFloating(dev) ? dev : GetMaster(dev, MASTER_POINTER);
- /* XI 2 event */
- btlen = (mouse->button) ? bits_to_bytes(mouse->button->numButtons) : 0;
+ /* XI 2 event contains the logical button map - maps are CARD8
+ * so we need 256 bits for the possibly maximum mapping */
+ btlen = (mouse->button) ? bits_to_bytes(256) : 0;
btlen = bytes_to_int32(btlen);
len = sizeof(xXIFocusInEvent) + btlen * 4;
--
2.33.0

View File

@ -0,0 +1,60 @@
From e5e8586a12a3ec915673edffa10dc8fe5e15dac3 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 6 May 2024 17:19:35 +0800
Subject: [PATCH] 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>
---
glx/glxcmds.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index fc26a2e..1e46d0c 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -48,6 +48,7 @@
#include "indirect_util.h"
#include "protocol-versions.h"
#include "glxvndabi.h"
+#include "xace.h"
static char GLXServerVendorName[] = "SGI";
@@ -1392,6 +1393,13 @@ DoCreatePbuffer(ClientPtr client, int screenNum, XID fbconfigId,
if (!pPixmap)
return BadAlloc;
+ err = XaceHook(XACE_RESOURCE_ACCESS, client, glxDrawableId, RT_PIXMAP,
+ pPixmap, RT_NONE, NULL, DixCreateAccess);
+ if (err != Success) {
+ (*pGlxScreen->pScreen->DestroyPixmap) (pPixmap);
+ return err;
+ }
+
/* Assign the pixmap the same id as the pbuffer and add it as a
* resource so it and the DRI2 drawable will be reclaimed when the
* pbuffer is destroyed. */
--
2.33.0

View File

@ -0,0 +1,42 @@
From 2ef0f1116c65d5cb06d7b6d83f8a1aea702c94f7 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan <ofourdan@redhat.com>
Date: Mon, 6 May 2024 17:27:34 +0800
Subject: [PATCH] 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>
---
hw/xwayland/xwayland-cursor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/xwayland/xwayland-cursor.c b/hw/xwayland/xwayland-cursor.c
index e3c1aaa..bd94b0c 100644
--- a/hw/xwayland/xwayland-cursor.c
+++ b/hw/xwayland/xwayland-cursor.c
@@ -431,7 +431,7 @@ static miPointerScreenFuncRec xwl_pointer_screen_funcs = {
Bool
xwl_screen_init_cursor(struct xwl_screen *xwl_screen)
{
- if (!dixRegisterPrivateKey(&xwl_cursor_private_key, PRIVATE_CURSOR_BITS, 0))
+ if (!dixRegisterPrivateKey(&xwl_cursor_private_key, PRIVATE_CURSOR, 0))
return FALSE;
return miPointerInitialize(xwl_screen->screen,
--
2.33.0

View File

@ -4,14 +4,19 @@
Summary: Xwayland
Name: xorg-x11-server-Xwayland
Version: 22.1.2
Release: 3
Release: 4
License: MIT
URL: http://www.x.org
Source0: https://www.x.org/pub/individual/xserver/%{pkgname}-%{version}.tar.xz
Patch1: 0001-fix-CVE-2024-31080.patch
Patch2: 0002-fix-CVE-2024-31081.patch
Patch3: 0003-fix-CVE-2023-6377.patch
Patch4: 0004-fix-CVE-2023-6478.patch
Patch5: 0005-fix-CVE-2023-6816.patch
Patch6: 0006-fix-CVE-2024-0408.patch
Patch7: 0007-fix-CVE-2024-0409.patch
Requires: xorg-x11-server-common
Requires: libEGL
Requires: libepoxy >= 1.5.5
@ -111,6 +116,9 @@ rm -Rf $RPM_BUILD_ROOT%{_localstatedir}/lib/xkb
%{_libdir}/pkgconfig/xwayland.pc
%changelog
* Mon May 06 2024 cenhuilin <cenhuilin@kylinos.cn> - 22.1.2-4
- fix CVE-2023-6377 CVE-2023-6478 CVE-2023-6816 CVE-2024-0408 CVE-2024-0409
* Sun Apr 28 2024 cenhuilin <cenhuilin@kylinos.cn> - 22.1.2-3
- fix CVE-2024-31080 CVE-2024-31081