Brief Summary: CVE-2026-50259 Stack Buffer Overflow in X.Org X Server XKB SetMap Request

Introduction

An incomplete bounds check in the X.Org X server's XKB extension allows any connected X client to overflow a stack buffer by exactly 9 bytes. The overflow can crash the server, and on systems where the X server still runs as root, it opens the door to local privilege escalation. CVE-2026-50259 has a CVSS score of 7.8. It was disclosed in a broader June 2026 X.Org security advisory that addressed nine vulnerabilities across the XKB, XSYNC, GLX, DRI2, and font subsystems.

The flaw is a direct consequence of an incomplete fix for CVE-2025-26597. The two-stage attack sequence that triggers it is deterministic, and the public commit message documents it in detail. The vulnerability was reported through Trend Micro's Zero Day Initiative (ZDI-CAN-30161).

Technical information

Root cause

CVE-2026-50259 is a stack-based buffer overflow (CWE-121) in the XKB extension of the X.Org X server. The function _XkbSetMapChecks() in xkb/xkb.c declares a fixed-size stack buffer:

CARD8 mapWidths[XkbMaxLegalKeyCode + 1];  // 256 elements

This buffer is passed to the helper function CheckKeyTypes(), which computes an index value nMaps by adding req->firstType + req->nTypes. When the XkbSetMapResizeTypes flag is set, both are client-controlled fields from the incoming XKB SetMap request. Before the patch, nothing checked that nMaps would stay within the size of the mapWidths stack buffer.

Attack flow

The GitLab commit by Peter Hutterer documents the exploitation technique, which is a precise two-stage sequence:

Stage 1: Inflate num_types

The attacker sends a SetMap request with firstType=0, nTypes=255, and the ResizeTypes flag set. The server's internal num_types value rises to 255. That gives the attacker a large valid key type range, which the next step uses to bypass validation.

Stage 2: Bypass validation and overflow

The attacker sends a second SetMap request with firstType=255 and nTypes=10. The existing bounds check used a strict greater-than comparison (firstType > num_types), which evaluates 255 > 255 as false. The request bypasses validation entirely, and the result is nMaps = 265. The loop that follows writes to indices 255 through 264. Those writes overflow 9 bytes past the 256-element mapWidths[] stack buffer and corrupt the adjacent symsPerKey[] stack variable.

Impact

The overflow has two possible outcomes, depending on the X server's execution context:

1. Denial of service: Corrupting the stack crashes the X server, which terminates every graphical session for every user on the system.
2. Privilege escalation: If the X server runs as root (a configuration still present in some legacy, embedded, and kiosk setups), the stack corruption may be exploitable for arbitrary code execution with root privileges.

Any X client that can connect to the X server can trigger this flaw. No special authentication beyond an active X session is required. Because the attack vector is local, an attacker needs prior access to the system, but on multi-user systems or systems already partially compromised, that is a realistic scenario.

Relationship to CVE-2025-26597

The X.Org advisory explicitly notes that CVE-2026-50259 stems from an incomplete fix for CVE-2025-26597, which also affected the XKB extension but failed to clamp shift levels properly. The regression suggests that the XKB validation logic has been through multiple incomplete patches, and that point fixes for individual bounds checks, made without a comprehensive validation audit, continue to leave gaps.

Patch information

Peter Hutterer wrote the upstream fix, which is commit 867b59b33bee669cb412f1314e47c52eacf6e00b in the xorg/xserver GitLab repository. The commit title is "xkb: clamp nMaps to mapWidths buffer size in CheckKeyTypes".

The fix adds a single bounds check gate in CheckKeyTypes() in xkb/xkb.c at line 1624:

if (nMaps > XkbMaxLegalKeyCode + 1) {
    *nMapsRtrn = _XkbErrCode4(0x02, req->firstType, req->nTypes,
                              XkbMaxLegalKeyCode + 1);
    return 0;
}

This check runs immediately after the existing validation of firstType + nTypes arithmetic. If the computed nMaps value exceeds XkbMaxLegalKeyCode + 1 (which equals 256, the exact capacity of the mapWidths stack buffer), the function records a diagnostic error code via _XkbErrCode4() and returns 0. The operation aborts before any out-of-bounds write can occur. Because _XkbErrCode4 carries the firstType, nTypes, and buffer limit, the server logs enough context for debugging and still rejects the malicious request cleanly.

This commit was included in xorg-server 21.1.23 and Xwayland 24.1.12, both published on June 2, 2026, as part of the X.Org Security Advisory that addressed nine vulnerabilities in total. The fix was part of merge request !2228 ("Fix a number of security issues"). Major Linux distributions, including Red Hat Enterprise Linux (versions 7 through 10), Fedora, Arch Linux, and Ubuntu, have begun shipping updated packages with this fix.

As of June 5, 2026, the Red Hat Bugzilla entry remained in NEW status with no official RPM errata released. Organizations running RHEL should monitor Red Hat errata channels for official package updates.

Because the June 2026 advisory addresses nine vulnerabilities across multiple subsystems, organizations should apply the full updated package rather than cherry-picking individual fixes.

Affected systems and versions

The vulnerability affects any system running the X.Org X server or Xwayland where an X client can connect to the server. This includes:

• Traditional X11 desktop sessions on Linux distributions
• Wayland sessions using Xwayland for backward compatibility with X11 applications
• Systems where the X server runs as root (legacy, embedded, or kiosk configurations), which are at elevated risk because of the privilege escalation potential
• Multi-user systems where untrusted users can establish X sessions

Vendor security history

The X.Org X server has a long, well-documented history of memory safety vulnerabilities, which follows naturally from a C codebase with roots in 1984. The X.Org Security Advisories page catalogs numerous CVEs across multiple years. Recent advisories include:

The June 2026 advisory alone contains seven vulnerabilities, spanning stack overflows, use-after-free, and heap corruption across five different subsystems, which points to a systemic pattern. The incomplete fix for CVE-2025-26597 that directly produced CVE-2026-50259 shows that patching individual bounds checks without comprehensive validation audits can introduce regressions. Most recent vulnerabilities were reported through Trend Micro's Zero Day Initiative, and Peter Hutterer of Red Hat also contributed internal discoveries.

For organizations still relying on the X.Org X server, this track record reinforces the case for accelerating migration to Wayland-based compositors where feasible. Xwayland will still carry some of this attack surface for backward compatibility.

References

• NVD Entry for CVE-2026-50259
• Red Hat CVE Page for CVE-2026-50259
• Red Hat Bugzilla: Bug 2485384
• GitLab Commit 867b59b3: xkb: clamp nMaps to mapWidths buffer size in CheckKeyTypes
• X.Org Security Advisory, June 2026
• X.Org Security Advisories Index
• X.Org Security Advisory, April 2026
• X.Org Security Advisory, June 2025
• CISA Known Exploited Vulnerabilities Catalog
• VulnCheck: Quantifying 2026 Routinely Targeted Vulnerabilities
• Greenbone: February 2026 Threat Report
• X Window System, Wikipedia