Brief Summary: CVE-2026-50258 Stack Buffer Overflow in X.Org X Server and Xwayland XKB Extension

Introduction

An incomplete fix for a 2025 XKB buffer overflow has left the X.Org X server and Xwayland open to a new stack overflow. It can crash the display server, and on legacy systems running X as root it can give an authenticated attacker full privilege escalation. CVE-2026-50258 has a CVSS score of 7.8. It was disclosed on June 2, 2026, in an X.Org security advisory covering nine vulnerabilities, seven of which were discovered through the TrendAI Zero Day Initiative.

Technical Information

Root Cause

CVE-2026-50258 is a stack-based buffer overflow (CWE-121) in the X Keyboard Extension (XKB) subsystem, in the CheckKeyTypes() function in xkb/xkb.c. The X server keeps several stack buffers sized XkbMaxShiftLevel * XkbNumKbdGroups for processing keyboard mapping data. CheckKeyTypes() historically validated only the lower bound of the numLevels (also called width) parameter, making sure it was not less than 1. It never checked the upper bound against XkbMaxShiftLevel, which is defined as 63.

A malicious X client could therefore submit key type definitions with numLevels set as high as 255, well above the architectural maximum. The server accepted and stored these oversized key types without complaint.

Relationship to CVE-2025-26597

This vulnerability comes directly from an incomplete prior fix. CVE-2025-26597, published February 25, 2025, covered a buffer overflow in XkbChangeTypesOfKey(): calling the function with a 0 group resized the key symbols table to 0 but left the key types unchanged, which led to a buffer overflow. That vulnerability was fixed in xorg-server 21.1.16 and xwayland 24.1.6. The 2025 fix did not address the related validation gap in CheckKeyTypes(), and that gap is what CVE-2026-50258 exploits. Both vulnerabilities sit in the XKB code path, and both come from failing to validate array indices against fixed-size internal buffers.

Attack Flow

The attack has two stages.

Stage 1: Poisoning the type table. An authenticated X client sends an XkbSetMap request containing a crafted key type definition where num_levels exceeds XkbMaxShiftLevel. Because CheckKeyTypes() neither rejects nor clamps this value, the server accepts the oversized key type and stores it in its internal type table. Nothing overflows yet.

Stage 2: Triggering the overflow. The overflow happens during a later core keyboard mapping change. When ChangeKeyboardMapping triggers XkbUpdateKeyTypesFromCore, the code path calls XkbKeyTypesForCoreSymbols. This function computes a groupsWidth value directly from the attacker-controlled num_levels, then uses the XKB_OFFSET macro to calculate indices into tsyms[], a stack-allocated buffer:

XKB_OFFSET(g, l) = (g * groupsWidth) + l

The tsyms[] buffer is sized for XkbMaxSymsPerKey (252 entries). With num_levels set to 255, groupsWidth becomes 255, and the computed indices can reach 3 * 255 + 254 = 1019. That overflows the 252-element stack buffer by 767 KeySym-sized entries. The same code path overflows three separate stack buffers, so an attacker has more than one place to corrupt memory.

Impact

A 767-entry overflow of a stack buffer gives an attacker substantial control over the stack frame, and an experienced attacker could feasibly overwrite the return address. Where the X server runs as root (still found in some legacy or embedded configurations), successful exploitation yields root-level privilege escalation. On Wayland-based systems, Xwayland typically runs under the user's session rather than as root, which limits the impact to user-level code execution. The crash, and the denial of service that comes with it, is possible regardless of privilege level.

Discovery

An anonymous researcher working with the TrendAI Zero Day Initiative found the vulnerability, tracked as ZDI-CAN-30160. It was disclosed in a coordinated advisory alongside eight other X.Org/Xwayland vulnerabilities on June 2, 2026.

Patch Information

The fix for CVE-2026-50258 is a single-line change authored by Peter Hutterer and committed on June 1, 2026, in commit 543e108516428fc8c3bea91d6563ad266f9a801e. It changes the CheckKeyTypes() function in xkb/xkb.c.

The patch extends the original check, if (width < 1), with the missing upper bound:

@@ -1652,7 +1652,7 @@ CheckKeyTypes(ClientPtr client,
     }
     n = i + req->firstType;
     width = wire->numLevels;
-    if (width < 1) {
+    if (width < 1 || width > XkbMaxShiftLevel) {
         *nMapsRtrn = _XkbErrCode3(0x04, n, width);
         return 0;
     }

The constant XkbMaxShiftLevel is defined as 63, the architectural maximum shift level in XKB. With || width > XkbMaxShiftLevel added to the existing bounds check, the function now rejects any key type that declares more levels than the protocol permits. A failed check returns an error code (0x04 with the type index and offending width) and denies the request, through the same error-handling path the width < 1 case already used.

The fix ships in xorg-server 21.1.23 and xwayland 24.1.12, both released on June 2, 2026. The related merge request on GitLab is !2228.

Organizations that cannot upgrade immediately can backport this small change directly from the commit.

Vendor-specific patches are also available:

Affected Systems and Versions

All versions of the X.Org X server before 21.1.23 and Xwayland before 24.1.12 are affected. The vulnerability was introduced in X11R6.1, so virtually every deployed version before the fix is vulnerable.

The risk depends on how the server is deployed:

• Systems running X server as root: Full privilege escalation is possible. This configuration is still present in some legacy and embedded deployments.
• Wayland-based systems with Xwayland: Xwayland typically runs under the user's session rather than as root, which limits the impact to user-level code execution and denial of service.
• All configurations: An attacker can crash the server, causing denial of service, regardless of privilege level.

Exploitation requires an authenticated X client connection, so the attacker needs either local access or a compromised user session. That confines the attack surface to local privilege escalation or post-compromise persistence rather than remote unauthenticated access.

Vendor Security History

The X.Org X server has a documented history of security vulnerabilities going back to at least 2006. The codebase's age (it originates from X11R6.1 in the mid-1990s) and the complexity of the X Window System protocol have contributed to recurring vulnerability classes, particularly buffer overflows and memory corruption in the XKB, GLX, XSYNC, and DRI2 extensions.

The February 2025 advisory (CVE-2025-26597 and companions) and the June 2026 advisory (CVE-2026-50258 and companions) both involve XKB stack buffer overflows caused by incomplete validation. The CVE-2025-26597 fix repaired XkbChangeTypesOfKey() and left CheckKeyTypes() unguarded. In a legacy codebase, fixing one code path without auditing all the related ones can leave residual weaknesses that are later discovered and reported as new CVEs.

Seven of the nine vulnerabilities in the June 2026 advisory were discovered by anonymous researchers working with the TrendAI Zero Day Initiative, which suggests the X server codebase is getting more attention from security researchers. XKB stack buffer overflows recurring across two consecutive CVEs also raises the question of whether more validation gaps remain in the XKB subsystem. Organizations should watch future X.Org advisories for further XKB-related CVEs.

References

• CVE-2026-50258, Red Hat Customer Portal
• Red Hat Bugzilla: Bug 2485383
• GitLab Commit: xkb: reject key types with num_levels exceeding XkbMaxShiftLevel
• cgit Commit: 543e108516428fc8c3bea91d6563ad266f9a801e
• X.Org Security Advisory, June 2026
• Red Hat Jira: PSIRTSUPT-16950
• CVE-2025-26597, Red Hat Customer Portal
• CVE-2025-26597 Detail, NVD
• Oracle Linux Errata: ELSA-2026-50258
• GitHub Advisory: GHSA-74fp-pmv2-rh3f
• SUSE Security Update: SUSE-SU-20261330-1
• X.Org Security Advisories
• CISA Known Exploited Vulnerabilities Catalog