Back in January we had some security issues revealed in both X.Org and Xwayland, and here we are with a few more and so there's new versions available for both to fix them.
The announcements came Wednesday, April 3rd with 4 issues noted in X.Org, 3 of which affected Xwayland too. You can see the details on each of the issues in the mailing list announcement. The issues are as noted:
- CVE-2024-31080: Heap buffer overread/data leakage in ProcXIGetSelectedEvents - The ProcXIGetSelectedEvents() function uses the byte-swapped length of the return data for the amount of data to return to the client, if the client has a different endianness than the X server.
- CVE-2024-31081: Heap buffer overread/data leakage in ProcXIPassiveGrabDevice - The ProcXIPassiveGrabDevice() function uses the byte-swapped length of the return data for the amount of data to return to the client, if the client has a different endianness than the X server.
- CVE-2024-31082: Heap buffer overread/data leakage in ProcAppleDRICreatePixmap - The ProcAppleDRICreatePixmap() function uses the byte-swapped length of the return data for the amount of data to return to the client, if the client has a different endianness than the X server. This function is only found in the Xquartz server for MacOS systems, and not in Xwayland, Xorg, or any other X servers.
- CVE-2024-31083: User-after-free in ProcRenderAddGlyphs - The ProcRenderAddGlyphs() function calls the AllocateGlyph() function to store new glyphs sent by the client to the X server. AllocateGlyph() would return a new glyph with refcount=0 and a re-used glyph would end up not changing the refcount at all. The resulting glyph_new array would thus have multiple entries pointing to the same non-refcounted glyphs. ProcRenderAddGlyphs() may free a glyph, resulting in a use-after-free when the same glyph pointer is then later used.
xorg-server 21.1.12 changelog:
This release addresses the following 4 security issues:
* CVE-2024-31080
* CVE-2024-31081
* CVE-2024-31082
* CVE-2024-31083Additionally it provides a way to disable byte-swapped clients either by command line flag or config option. This allows to turn off byte swapping code that has been a source of security problems lately.
xwayland 23.2.5 changelog:
This release contains the 3 security fixes that actually apply to
Xwayland reported in today's security advisory:* CVE-2024-31080
* CVE-2024-31081
* CVE-2024-31083Additionally, it also contains a couple of other fixes, a copy/paste error in the DeviceStateNotify event and a fix to enable buttons with pointer gestures for backward compatibility with legacy X11 clients.
i hope bsd devs are watching this
Quoting: nenoro2024 > the year of vulnerabilities for packages on linux.In the context of the xorg server, openbsd has has openbsd specific security patches in the xorg server that restricts what it can do (by using pledge for example) which might help against these issues. So even if software on openbsd is hacked the hack is rendered useless or has less impact.
i hope bsd devs are watching this
Quoting: nnohonsjnhtsylayQuoting: nenoro2024 > the year of vulnerabilities for packages on linux.In the context of the xorg server, openbsd has has openbsd specific security patches in the xorg server that restricts what it can do (by using pledge for example) which might help against these issues. So even if software on openbsd is hacked the hack is rendered useless or has less impact.
i hope bsd devs are watching this
I wonder why bsd restrict this function ?
Quoting: nenoroI wonder why bsd restrict this function ?openbsd does that in all programs. Instead of relying on software being perfect with no bugs, if there is a bug and somebody takes advantage of that (a malicious actor) then it has restricted access, minimizing the impact of the vulnerability. Its kinda like what browsers do in tabs, on linux too. If there is a browser vulnerability and a website with javascript tries to use that to do malicious things then the tab is automatically killed by the kernel.
See more from me