This vulnerability allows local attackers to escalate privileges on affected installations of X.Org Server. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2026-56001.

glamorfontget() builds a per-font texture atlas by laying out every glyph in the font into a single backing buffer. It computes the slot dimensions from the font's declared maxbounds, but copies each per-glyph bitmap using the individual glyph's metrics (GLYPHHEIGHTPIXELS/GLYPHWIDTHBYTES macros). There is no check that maxbounds actually bounds the per-glyph values.

When the font is loaded from a malicious PCF file whose per-glyph metrics exceed the file's maxbounds, the per-glyph memcpy writes far beyond the heap-allocated slot, producing a heap buffer overflow with attacker-controlled extent and attacker-controlled content.

An authenticated X client can trigger this by using SetFontPath to add a directory containing a crafted PCF font, loading the font with OpenFont, and drawing text on a glamor-backed drawable. Only servers using the glamor acceleration backend (Xorg with modesetting driver, Xwayland) are affected.

glamorfontget() builds a per-font texture atlas by laying out every glyph in the font into a single backing buffer. It computes the slot dimensions from the font's declared maxbounds, but copies each per-glyph bitmap using the individual glyph's metrics (GLYPHHEIGHTPIXELS/GLYPHWIDTHBYTES macros). There is no check that maxbounds actually bounds the per-glyph values.

When the font is loaded from a malicious PCF file whose per-glyph metrics exceed the file's maxbounds, the per-glyph memcpy writes far beyond the heap-allocated slot, producing a heap buffer overflow with attacker-controlled extent and attacker-controlled content.

An authenticated X client can trigger this by using SetFontPath to add a directory containing a crafted PCF font, loading the font with OpenFont, and drawing text on a glamor-backed drawable. Only servers using the glamor acceleration backend (Xorg with modesetting driver, Xwayland) are affected.

This vulnerability allows local attackers to escalate privileges on affected installations of X.Org Server. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2026-50257.

This vulnerability allows local attackers to escalate privileges on affected installations of X.Org Server. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2026-50258.

This vulnerability allows local attackers to disclose sensitive information on affected installations of X.Org Server. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 5.5. The following CVEs are assigned: CVE-2026-50263.

This vulnerability allows local attackers to escalate privileges on affected installations of X.Org Server. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2026-34003.

A client that requests multiple DRI2BufferBackLeft attachments and one DRI2BufferFrontLeft can trigger an out-of-bounds heap write in DRIGetBuffers/DRIGetBuffersWithFormat.

Any local X client that can connect to the server can trigger this issue. This may be used to crash the server, or for privilege escalation if the X server runs as root.

Components affected: xorg-x11-server, xorg-x11-server-Xwayland Versions affected: xorg-x11-server <= 21.1.22, xorg-x11-server-Xwayland <= 24.1.9

Fixed upstream in xorg-server-21.1.23 and xwayland-24.1.12. Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/339c279514326134b0878fc23ce6e9520440ce7f

Identified by Peter Hutterer, Red Hat. Tracking: PSIRTSUPT-16950.

Please update

On Wed, Aug 13, 2025 at 07:00:58PM +0200, Vincent Lefevre wrote: The following makes the xterm terminal crash

touch "$(printf "file\e[H\e[c\n\b")" gunzip file

due to malicious character sequences in the file name and a bug in xterm. Same issue with bunzip2 instead of gunzip. I do not expect this to only happen with gunzip and bzip2. Does this happen with any program that prints the filename without any escaping, e.g., "echo file", and most programs that print the provided filename ...

On Aug 17, 2025, at 10:09 AM, Erik Auerswald <auerswal () unix-ag uni-kl de> wrote: I'd expect most programs to not change the filename printed in their output. POSIX does not even expect "ls" to sanitize its output without "-q", but it does allow it[0]. Two more example programs that do not sanitize filenames in their output would be "file", at least version "5.41", and "dash", at least the version[1] included in Ubuntu GNU/Linux 22.04.5 LTS. I'd expect that you can find many more examples. Getting every program changed to follow your expectation seems like a Sisyphean task to me.

Please note that I am not opposed to adding that feature to every existing and future program, it just seems foolish to rely on it, at least currently. I agree. It'd be much more secure if the operating simply prevented the creation of filenames with certain names, e.g,. containing control characters and leading dashes. I wrote an essay here specifically about this: https://dwheeler.com/essays/fixing-unix-linux-filenames.html See section 1.3, "Oh, and don’t display filenames. Filenames could contain control characters that control the terminal (and X-windows), causing nasty side-effects on display. Displaying filenames can even cause a security vulnerability — and who expects printing a filename to be a vulnerability?!?" It's not a new problem, I knew about this in the 1980s and I'm sure others did too.

I proposed forbidding such characters to POSIX. They did add a few mechanisms to POSIX to make it somewhat easier to handle filenames with control characters (e.g., find -print0 and xargs -0). However, although they do not require that operating systems allow these filenames, they are not forbidden either.

I have a draft Linux Security Module (LSM) that lets you determine what kind of filenames are allowed to be created. By default it would require non-control-chars, no leading '-', no trailing ' ', and UTF-8 encoding, but it would let you configure further. I intend to go back to that to finish it off & propose it. My original proposal merely prevented creation; it would be possible to hide them entirely, but that comes with its own issues.

--- David A. Wheeler

Hi,

On Wed, Aug 13, 2025 at 07:00:58PM +0200, Vincent Lefevre wrote: The following makes the xterm terminal crash

touch "$(printf "file\e[H\e[c\n\b")" gunzip file

due to malicious character sequences in the file name and a bug in xterm. Same issue with bunzip2 instead of gunzip. I do not expect this to only happen with gunzip and bzip2. Does this happen with any program that prints the filename without any escaping, e.g., "echo file", and most programs that print the provided filename when reporting any associated problem (i.e., all that do not escape or suppress non-printable filename characters or bytes)? [...] Best regards, Erik

This vulnerability allows local attackers to escalate privileges on affected installations of X.Org Server. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2025-26594.

This vulnerability allows local attackers to escalate privileges on affected installations of X.Org Server. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2025-26596.

This vulnerability allows local attackers to escalate privileges on affected installations of X.Org Server. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2025-26595.

This vulnerability allows local attackers to escalate privileges on affected installations of X.Org Server. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2024-0229.

Xwayland is an X server for running X clients under Wayland.<br>Security Fix(es):<br><li> xorg-x11-server: buffer overflow in GetCountedString() in xkb/xkb.c (CVE-2022-3550)</li> <li> xorg-x11-server: XkbGetKbdByName use-after-free (CVE-2022-4283)</li> <li> xorg-x11-server: XTestSwapFakeInput stack overflow (CVE-2022-46340)</li> <li> xorg-x11-server: XIPassiveUngrab out-of-bounds access (CVE-2022-46341)</li> <li> xorg-x11-server: XvdiSelectVideoNotify use-after-free (CVE-2022-46342)</li> <li> xorg-x11-server: ScreenSaverSetAttributes use-after-free (CVE-2022-46343)</li> <li> xorg-x11-server: XIChangeProperty out-of-bounds access (CVE-2022-46344)</li> <li> xorg-x11-server: DeepCopyPointerClasses use-after-free leads to privilege elevation (CVE-2023-0494)</li> <li> xorg-x11-server: memory leak in ProcXkbGetKbdByName() in xkb/xkb.c (CVE-2022-3551)</li> For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.<br>Additional Changes:<br>For detailed information on changes in this release, see the Red Hat Enterprise Linux 8.8 Release Notes linked from the References section.

It was found that XKB actions for debugging X.org clients were enabled by default. This could cause a screen locking application such as gnome-screensaver to be killed when those key combinations were triggered.

The debugging key actions were introduced in the following commit: http://cgit.freedesktop.org/xorg/xserver/commit/?id=7d2543a3cb3089241982ce4f8984fd723d5312a1

Reference: http://thread.gmane.org/gmane.comp.security.oss.general/6725

Mitigation: http://thread.gmane.org/gmane.comp.security.oss.general/6725/focus=6731