FreshPorts - VuXML

The X.Org project reports:

• ZDI-CAN-22153/CVE-2023-5367: X.Org server: OOB write in XIChangeDeviceProperty/RRChangeOutputProperty

  When prepending values to an existing property an invalid offset calculation causes the existing values to be appended at the wrong offset. The resulting memcpy() would write into memory outside the heap-allocated array.

• ZDI-CAN-21608/CVE-2023-5380: Use-after-free bug in DestroyWindow

  This vulnerability requires a legacy multi-screen setup with multiple protocol screens ("Zaphod"). If the pointer is warped from one screen to the root window of the other screen, the enter/leave code may retain a reference to the previous pointer window. Destroying this window leaves that reference in place, other windows may then trigger a use-after-free bug when they are destroyed.

< 21.1.9,1

< 21.1.9,2

< 23.2.2,1

< 21.0.99.1.542

The X.org project reports:

These issues can lead to privileges elevations for authorized clients on systems where the X server is running privileged.

Insufficient checks on the lengths of the XkbSetMap request can lead to out of bounds memory accesses in the X server.

Insufficient checks on input of the XkbSetDeviceInfo request can lead to a buffer overflow on the head in the X server.

< 1.20.9_1,1

< 1.20.9_1,1

< 1.20.9_1,1

< 1.20.9_1,1

< 1.20.9_2,1

< 1.20.9_1,1

The X.org project reports:

All theses issuses can lead to local privileges elevation on systems where the X server is running privileged.

The handler for the XkbSetNames request does not validate the request length before accessing its contents.

An integer underflow exists in the handler for the XIChangeHierarchy request.

An integer underflow exist in the handler for the XkbSelectEvents request.

An integer underflow exist in the handler for the CreateRegister request of the X record extension.

< 1.20.8_4,1

< 1.20.8_4,1

< 1.20.8_4,1

< 1.20.8_4,1

< 1.20.8_4,1

< 1.20.8_4,1

The X.org project reports:

Allocation for pixmap data in AllocatePixmap() does not initialize the memory in xserver, it leads to leak uninitialize heap memory to clients. When the X server runs with elevated privileges.

This flaw can lead to ASLR bypass, which when combined with other flaws (known/unknown) could lead to lead to privilege elevation in the client.

< 1.20.8_3,1

< 1.20.8_3,1

< 1.20.8_3,1

< 1.20.8_3,1

< 1.20.8_3,1

< 1.20.8_3,1

X.Org server security reports for release 1.20.11:

• Fix XChangeFeedbackControl() request underflow

.

< 1.20.11,1

< 1.20.11,1

le 1.20.0.877

The X.org project reports:

• CVE-2022-46340/ZDI-CAN-19265: X.Org Server XTestSwapFakeInput stack overflow

  The swap handler for the XTestFakeInput request of the XTest extension may corrupt the stack if GenericEvents with lengths larger than 32 bytes are sent through a the XTestFakeInput request.

  This issue does not affect systems where client and server use the same byte order.

• CVE-2022-46341/ZDI-CAN-19381: X.Org Server XIPassiveUngrab out-of-bounds access

  The handler for the XIPassiveUngrab request accesses out-of-bounds memory when invoked with a high keycode or button code.

• CVE-2022-46342/ZDI-CAN-19400: X.Org Server XvdiSelectVideoNotify use-after-free

  The handler for the XvdiSelectVideoNotify request may write to memory after it has been freed.

• CVE-2022-46343/ZDI-CAN-19404: X.Org Server ScreenSaverSetAttributes use-after-free

  The handler for the ScreenSaverSetAttributes request may write to memory after it has been freed.

• CVE-2022-46344/ZDI-CAN-19405: X.Org Server XIChangeProperty out-of-bounds access

  The handler for the XIChangeProperty request has a length-validation issues, resulting in out-of-bounds memory reads and potential information disclosure.

• CVE-2022-4283/ZDI-CAN-19530: X.Org Server XkbGetKbdByName use-after-free

  The XkbCopyNames function left a dangling pointer to freed memory, resulting in out-of-bounds memory access on subsequent XkbGetKbdByName requests.

< 21.1.5,1

< 21.1.5,2

< 22.1.6,1

< 21.0.99.1.319

The X.org project reports:

• CVE-2023-0494/ZDI-CAN-19596: X.Org Server DeepCopyPointerClasses use-after-free

  A dangling pointer in DeepCopyPointerClasses can be exploited by ProcXkbSetDeviceInfo() and ProcXkbGetDeviceInfo() to read/write into freed memory.

< 21.1.7,1

< 21.1.7,2

< 22.1.8,1

< 21.0.99.1.386

The X.Org project reports:

• ZDI-CAN-19866/CVE-2023-1393: X.Org Server Overlay Window Use-After-Free Local Privilege Escalation Vulnerability

  If a client explicitly destroys the compositor overlay window (aka COW), the Xserver would leave a dangling pointer to that window in the CompScreen structure, which will trigger a use-after-free later.

< 21.1.8,1

< 21.1.8,2

ge 23.0.0,1 lt 23.1.1,1

< 22.1.9,1

< 21.0.99.1.439

The X.Org project reports:

• CVE-2023-6377/ZDI-CAN-22412/ZDI-CAN-22413: X.Org server: Out-of-bounds memory write in XKB button actions

  A device has XKB button actions for each button on the device. When a logical device switch happens (e.g. moving from a touchpad to a mouse), the server re-calculates the information available on the respective master device (typically the Virtual Core Pointer). This re-calculation only allocated enough memory for a single XKB action rather instead of enough for the newly active physical device's number of button. As a result, querying or changing the XKB button actions results in out-of-bounds memory reads and writes.

  This may lead to local privilege escalation if the server is run as root or remote code execution (e.g. x11 over ssh).

• CVE-2023-6478/ZDI-CAN-22561: X.Org server: Out-of-bounds memory read in RRChangeOutputProperty and RRChangeProviderProperty

  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->nUnits 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.

< 21.1.10,1

< 21.1.10,2

< 23.2.3,1

< 21.0.99.1.582