FreshPorts - VuXML

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:

• 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-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

Peter Hutterer reports:

Olivier Fourdan from Red Hat has discovered a protocol handling issue in the way the X server code base handles the XkbSetGeometry request.

The issue stems from the server trusting the client to send valid string lengths in the request data. A malicious client with string lengths exceeding the request length can cause the server to copy adjacent memory data into the XKB structs. This data is then available to the client via the XkbGetGeometry request. The data length is at least up to 64k, it is possible to obtain more data by chaining strings, each string length is then determined by whatever happens to be in that 16-bit region of memory.

A similarly crafted request can likely cause the X server to crash.

< 1.14.7_2,1

ge 1.15.0,1 lt 1.16.4,1

Alan Coopersmith reports:

Ilja van Sprundel, a security researcher with IOActive, has discovered a large number of issues in the way the X server code base handles requests from X clients, and has worked with X.Org's security team to analyze, confirm, and fix these issues.

The vulnerabilities could be exploited to cause the X server to access uninitialized memory or overwrite arbitrary memory in the X server process. This can cause a denial of service (e.g., an X server segmentation fault), or could be exploited to achieve arbitrary code execution.

The GLX extension to the X Window System allows an X client to send X protocol to the X server, to request that the X server perform OpenGL rendering on behalf of the X client. This is known as "GLX indirect rendering", as opposed to "GLX direct rendering" where the X client submits OpenGL rendering commands directly to the GPU, bypassing the X server and avoiding the X server code for GLX protocol handling.

Most GLX indirect rendering implementations share some common ancestry, dating back to "Sample Implementation" code from Silicon Graphics, Inc (SGI), which SGI originally commercially licensed to other Unix workstation and graphics vendors, and later released as open source, so those vulnerabilities may affect other licensees of SGI's code base beyond those running code from the X.Org Foundation or the XFree86 Project.

< 1.12.4_10,1

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:

• 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

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

xorg-server developers reports:

In the X.Org X server before 2017-06-19, a user authenticated to an X Session could crash or execute code in the context of the X Server by exploiting a stack overflow in the endianness conversion of X Events.

Uninitialized data in endianness conversion in the XEvent handling of the X.Org X Server before 2017-06-19 allowed authenticated malicious users to access potentially privileged data from the X server.

le 1.18.4_6,1

ge 1.19.0,1 le 1.19.3,1

Alan Coopersmith reports:

X.Org thanks Michal Srb of SuSE for finding these issues and bringing them to our attention, Julien Cristau of Debian for getting the fixes integrated, and Adam Jackson of Red Hat for publishing the release.

< 1.18.4_4,1

< 1.18.4_4,1

< 1.19.1_1,2

< 1.18.4_4,1

< 1.19.1_1,1

< 1.19.1_1

Adam Jackson reports:

One regression fix since 1.19.4 (mea culpa), and fixes for CVEs 2017-12176 through 2017-12187.

< 1.18.4_5,1

< 1.18.4_5,1

< 1.19.1_2,2

< 1.18.4_5,1

< 1.19.1_2,1

< 1.19.1_2

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:

• 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:

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

The X.Org project reports:

• CVE-2023-6816: Heap buffer overflow in DeviceFocusEvent and ProcXIQueryPointer

  Both DeviceFocusEvent and the XIQueryPointer reply contain a bit for each logical button currently down. Buttons can be arbitrarily mapped to any value up to 255 but the X.Org Server was only allocating space for the device's number of buttons, leading to a heap overflow if a bigger value was used.

• CVE-2024-0229: Reattaching to different master device may lead to out-of-bounds memory access

  If a device has both a button class and a key class and numButtons is zero, we can get an out-of-bounds write due to event under-allocation in the DeliverStateNotifyEvent function.

• CVE-2024-21885: Heap buffer overflow in XISendDeviceHierarchyEvent

  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, leading to a heap buffer overflow.

• CVE-2024-21886: Heap buffer overflow in DisableDevice

  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.

< 21.1.11,1

< 21.1.11,2

< 23.2.4

< 21.0.99.1.653