parent
55924763f0
commit
0790f1285e
@ -0,0 +1,80 @@
|
||||
From a31ba141824a7649e11f0ef7673718ce559d6337 Mon Sep 17 00:00:00 2001
|
||||
From: Peter Hutterer <peter.hutterer@who-t.net>
|
||||
Date: Tue, 3 Oct 2023 11:53:05 +1000
|
||||
Subject: [PATCH xserver 1/4] 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>
|
||||
---
|
||||
Xi/xiproperty.c | 4 ++--
|
||||
randr/rrproperty.c | 4 ++--
|
||||
2 files changed, 4 insertions(+), 4 deletions(-)
|
||||
|
||||
diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
|
||||
index 6ec419e870..563c4f31a5 100644
|
||||
--- a/Xi/xiproperty.c
|
||||
+++ b/Xi/xiproperty.c
|
||||
@@ -730,7 +730,7 @@ XIChangeDeviceProperty(DeviceIntPtr dev, Atom property, Atom type,
|
||||
XIDestroyDeviceProperty(prop);
|
||||
return BadAlloc;
|
||||
}
|
||||
- new_value.size = len;
|
||||
+ new_value.size = total_len;
|
||||
new_value.type = type;
|
||||
new_value.format = format;
|
||||
|
||||
@@ -747,7 +747,7 @@ XIChangeDeviceProperty(DeviceIntPtr dev, Atom property, Atom type,
|
||||
case PropModePrepend:
|
||||
new_data = new_value.data;
|
||||
old_data = (void *) (((char *) new_value.data) +
|
||||
- (prop_value->size * size_in_bytes));
|
||||
+ (len * size_in_bytes));
|
||||
break;
|
||||
}
|
||||
if (new_data)
|
||||
diff --git a/randr/rrproperty.c b/randr/rrproperty.c
|
||||
index c2fb9585c6..25469f57b2 100644
|
||||
--- a/randr/rrproperty.c
|
||||
+++ b/randr/rrproperty.c
|
||||
@@ -209,7 +209,7 @@ RRChangeOutputProperty(RROutputPtr output, Atom property, Atom type,
|
||||
RRDestroyOutputProperty(prop);
|
||||
return BadAlloc;
|
||||
}
|
||||
- new_value.size = len;
|
||||
+ new_value.size = total_len;
|
||||
new_value.type = type;
|
||||
new_value.format = format;
|
||||
|
||||
@@ -226,7 +226,7 @@ RRChangeOutputProperty(RROutputPtr output, Atom property, Atom type,
|
||||
case PropModePrepend:
|
||||
new_data = new_value.data;
|
||||
old_data = (void *) (((char *) new_value.data) +
|
||||
- (prop_value->size * size_in_bytes));
|
||||
+ (len * size_in_bytes));
|
||||
break;
|
||||
}
|
||||
if (new_data)
|
||||
--
|
||||
2.41.0
|
||||
|
@ -0,0 +1,99 @@
|
||||
From 004f461c440cb6611eefb48fbbb4fa53a6d49f80 Mon Sep 17 00:00:00 2001
|
||||
From: Peter Hutterer <peter.hutterer@who-t.net>
|
||||
Date: Thu, 5 Oct 2023 12:19:45 +1000
|
||||
Subject: [PATCH xserver 2/4] 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>
|
||||
---
|
||||
dix/enterleave.h | 2 --
|
||||
include/eventstr.h | 3 +++
|
||||
mi/mipointer.c | 17 +++++++++++++++--
|
||||
3 files changed, 18 insertions(+), 4 deletions(-)
|
||||
|
||||
diff --git a/dix/enterleave.h b/dix/enterleave.h
|
||||
index 4b833d8a3b..e8af924c68 100644
|
||||
--- a/dix/enterleave.h
|
||||
+++ b/dix/enterleave.h
|
||||
@@ -58,8 +58,6 @@ extern void DeviceFocusEvent(DeviceIntPtr dev,
|
||||
|
||||
extern void EnterWindow(DeviceIntPtr dev, WindowPtr win, int mode);
|
||||
|
||||
-extern void LeaveWindow(DeviceIntPtr dev);
|
||||
-
|
||||
extern void CoreFocusEvent(DeviceIntPtr kbd,
|
||||
int type, int mode, int detail, WindowPtr pWin);
|
||||
|
||||
diff --git a/include/eventstr.h b/include/eventstr.h
|
||||
index bf3b95fe4a..2bae3b0767 100644
|
||||
--- a/include/eventstr.h
|
||||
+++ b/include/eventstr.h
|
||||
@@ -296,4 +296,7 @@ union _InternalEvent {
|
||||
#endif
|
||||
};
|
||||
|
||||
+extern void
|
||||
+LeaveWindow(DeviceIntPtr dev);
|
||||
+
|
||||
#endif
|
||||
diff --git a/mi/mipointer.c b/mi/mipointer.c
|
||||
index 75be1aeeb8..b12ae9be1d 100644
|
||||
--- a/mi/mipointer.c
|
||||
+++ b/mi/mipointer.c
|
||||
@@ -397,8 +397,21 @@ miPointerWarpCursor(DeviceIntPtr pDev, ScreenPtr pScreen, int x, int y)
|
||||
#ifdef PANORAMIX
|
||||
&& noPanoramiXExtension
|
||||
#endif
|
||||
- )
|
||||
- UpdateSpriteForScreen(pDev, pScreen);
|
||||
+ ) {
|
||||
+ DeviceIntPtr master = GetMaster(pDev, MASTER_POINTER);
|
||||
+ /* Hack for CVE-2023-5380: if we're moving
|
||||
+ * screens PointerWindows[] keeps referring to the
|
||||
+ * old window. If that gets destroyed we have a UAF
|
||||
+ * bug later. Only happens when jumping from a window
|
||||
+ * to the root window on the other screen.
|
||||
+ * Enter/Leave events are incorrect for that case but
|
||||
+ * too niche to fix.
|
||||
+ */
|
||||
+ LeaveWindow(pDev);
|
||||
+ if (master)
|
||||
+ LeaveWindow(master);
|
||||
+ UpdateSpriteForScreen(pDev, pScreen);
|
||||
+ }
|
||||
}
|
||||
|
||||
/**
|
||||
--
|
||||
2.41.0
|
||||
|
@ -0,0 +1,74 @@
|
||||
From 0c1a93d319558fe3ab2d94f51d174b4f93810afd Mon Sep 17 00:00:00 2001
|
||||
From: Peter Hutterer <peter.hutterer@who-t.net>
|
||||
Date: Tue, 28 Nov 2023 15:19:04 +1000
|
||||
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 dcd4efb3bc..54ea11a938 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 b063128df0..3f3224d626 100644
|
||||
--- a/dix/devices.c
|
||||
+++ b/dix/devices.c
|
||||
@@ -2539,6 +2539,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,
|
||||
@@ -2549,6 +2551,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));
|
||||
--
|
||||
GitLab
|
@ -0,0 +1,59 @@
|
||||
From 3e0222fcae552685d423914a683c1709dc5f6d6b Mon Sep 17 00:00:00 2001
|
||||
From: Peter Hutterer <peter.hutterer@who-t.net>
|
||||
Date: Mon, 27 Nov 2023 16:27:49 +1000
|
||||
Subject: [PATCH xserver] 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-XXXXX, 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 25469f57b2..c4fef8a1f6 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 b79c17f9bf..90c5a9a933 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.43.0
|
||||
|
Loading…
Reference in new issue