apply upstream change 3e77295f888c67fc7645db5d0c00926a29ffecee

Subject: [PATCH] Xi: ProcXIPassiveGrabDevice needs to use unswapped length to
send reply

CVE-2024-31081

apply upstream change 96798fc1967491c80a4d0c8d9e0a80586cb2152b


Subject: [PATCH] Xi: ProcXIGetSelectedEvents needs to use unswapped length to
send reply

CVE-2024-31080

merge upstream change 4a5e9b1895627d40d26045bd0b7ef3dce503cbd1


Subject: [PATCH] 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

merge upstream change ece23be888a93b741aa1209d1dbf64636109d6a5 but into
Xi/exevents.c instead of dix/enterleave.c.


Subject: [PATCH] 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

merge upstream change 9e2ecb2af8302dedc49cb6a63ebe063c58a9e7e3 though the
enterleave.c portion msut be applied to Xi/exevents.c:DeviceFocusEvent().


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

merge upstream change 8f454b793e1f13c99872c15f0eed1d7f3b823fe8:

Subject: [PATCH] Xi: avoid integer truncation in length check of
ProcXIChangeProperty

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

merge security fixes from xorg-server 21.1.9 into xorg-server 10.

Fixes CVE-2023-5367 and CVE-2023-5380.

pullover fix from xorg-server 21.1.7:

https://gitlab.freedesktop.org/xorg/xserver/-/commit/0ba6d8c37071131a49790243cdac55392ecf71ec

Xi: fix potential use-after-free in DeepCopyPointerClasses

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's avatarPeter Hutterer <peter.hutterer@who-t.net>

pull across the fixes for CVE-2021-3472.

apply fixes for CVEs 2017-12176 to 2017-12187 to xorg-server 1.10.
several of the changes were in new code, and the DGA code had moved.

--
From 1b1d4c04695dced2463404174b50b3581dbd857b Mon Sep 17 00:00:00 2001
From: Nathan Kidd <nkidd@opentext.com>
Date: Sun, 21 Dec 2014 01:10:03 -0500
Subject: hw/xfree86: unvalidated lengths

This addresses:
CVE-2017-12180 in XFree86-VidModeExtension
CVE-2017-12181 in XFree86-DGA
CVE-2017-12182 in XFree86-DRI
--
From 211e05ac85a294ef361b9f80d689047fa52b9076 Mon Sep 17 00:00:00 2001
From: Michal Srb <msrb@suse.com>
Date: Fri, 7 Jul 2017 17:21:46 +0200
Subject: Xi: Test exact size of XIBarrierReleasePointer

Otherwise a client can send any value of num_barriers and cause reading or swapping of values on heap behind the receive buffer.
--
From 4ca68b878e851e2136c234f40a25008297d8d831 Mon Sep 17 00:00:00 2001
From: Nathan Kidd <nkidd@opentext.com>
Date: Fri, 9 Jan 2015 10:09:14 -0500
Subject: dbe: Unvalidated variable-length request in ProcDbeGetVisualInfo
(CVE-2017-12177)

v2: Protect against integer overflow (Alan Coopersmith)
--
From 55caa8b08c84af2b50fbc936cf334a5a93dd7db5 Mon Sep 17 00:00:00 2001
From: Nathan Kidd <nkidd@opentext.com>
Date: Fri, 9 Jan 2015 11:43:05 -0500
Subject: xfixes: unvalidated lengths (CVE-2017-12183)

v2: Use before swap (Jeremy Huddleston Sequoia)

v3: Fix wrong XFixesCopyRegion checks (Alan Coopersmith)
--
From 859b08d523307eebde7724fd1a0789c44813e821 Mon Sep 17 00:00:00 2001
From: Nathan Kidd <nkidd@opentext.com>
Date: Wed, 24 Dec 2014 16:22:18 -0500
Subject: Xi: fix wrong extra length check in ProcXIChangeHierarchy
(CVE-2017-12178)
--
From 9c23685009aa96f4b861dcc5d2e01dbee00c4dd9 Mon Sep 17 00:00:00 2001
From: Michal Srb <msrb@suse.com>
Date: Fri, 7 Jul 2017 17:04:03 +0200
Subject: os: Make sure big requests have sufficient length.

A client can send a big request where the 32B "length" field has value
0. When the big request header is removed and the length corrected,
the value will underflow to 0xFFFFFFFF. Functions processing the
request later will think that the client sent much more data and may
touch memory beyond the receive buffer.
--
From b747da5e25be944337a9cd1415506fc06b70aa81 Mon Sep 17 00:00:00 2001
From: Nathan Kidd <nkidd@opentext.com>
Date: Fri, 9 Jan 2015 10:15:46 -0500
Subject: Unvalidated extra length in ProcEstablishConnection (CVE-2017-12176)

add missing } from the previous. apparently i mis-tested and it didn't compile.

CVE-2017-10971 and CVE-2017-10972: apply fixes to the event loop from

https://cgit.freedesktop.org/xorg/xserver/commit/?id=ba336b24052122b136486961c82deac76bbde455
https://cgit.freedesktop.org/xorg/xserver/commit/?id=8caed4df36b1f802b4992edcfd282cbeeec35d9d
https://cgit.freedesktop.org/xorg/xserver/commit/?id=215f894965df5fb0bb45b107d84524e700d2073c
https://cgit.freedesktop.org/xorg/xserver/commit/?id=05442de962d3dc624f79fc1a00eca3ffc5489ced

XXX: pullup-[678] (6/7 also need xfree port.)

initial import of existing netbsd xorg-server 1.10 sources in the
xorg-server.old subdir.