Brief Summary: CVE-2026-50264 — X.Org X Server DRI2 Out-of-Bounds Heap Write via Duplicate Buffer Attachments

Introduction

A missing input-validation check in the X.Org X server's DRI2 extension, present in the codebase for years, lets a local attacker trigger an out-of-bounds heap write by sending duplicate buffer attachment types in a single request. On systems where the X server still runs as root, an attacker can use this heap corruption for local privilege escalation. That makes it a real concern for any organization that maintains Linux desktops or workstations.

CVE-2026-50264 was disclosed on June 2, 2026 as part of a batch of nine X.Org security vulnerabilities, some of which were found through AI-assisted code analysis. NVD gives it a CVSS score of 7.8 (High). Red Hat is more conservative at 5.9 (Medium), and the gap reflects different views on how hard the bug is to exploit in practice.

Technical Information

Root Cause

The vulnerability is in the do_get_buffers() function in hw/xfree86/dri2/dri2.c. This function processes DRI2 buffer attachment requests from X clients. The DRI2 protocol was always designed on the assumption that each buffer attachment type (such as DRI2BufferBackLeft, DRI2BufferFrontLeft, and DRI2BufferFakeFrontLeft) would appear at most once per request. Mesa, the standard client-side implementation, honored this assumption. The X server, however, never enforced it.

The original code tracked the state of the front buffers with integer counters:

// BEFORE:
int need_real_front = 0;
int need_fake_front = 0;
int have_fake_front = 0;
...
need_real_front++;   // on DRI2BufferBackLeft
need_real_front--;   // on DRI2BufferFrontLeft
need_fake_front++;   // on DRI2BufferFrontLeft for windows
need_fake_front--;   // on DRI2BufferFakeFrontLeft

Requesting DRI2BufferBackLeft several times would increment need_real_front several times, while a single DRI2BufferFrontLeft would decrement it only once. The counter stayed positive, so the server allocated more buffers than expected.

Heap Corruption Mechanism

The server sized the buffer array from the raw client-provided count:

buffers = calloc((count + 1), sizeof(buffers[0]));

There are only 11 valid DRI2 attachment types, with DRI2BufferHiz as the highest value. A malicious client that sends, say, 50 duplicate DRI2BufferBackLeft entries would make the server process and write buffer entries well beyond the bounds of any reasonably sized array. The server allocated one buffer per request entry without deduplication, so it wrote past the end of the heap-allocated buffers array.

This opens two distinct corruption paths:

1. An out-of-bounds heap write. The server writes buffer pointers and metadata beyond the allocated array and corrupts adjacent heap objects.
2. A possible double free. When duplicate attachments reference the same underlying buffer, destroy_buffer may be called more than once for the same DRI2BufferPtr, which corrupts the heap further.

Attack Flow

An attacker with local access to the X server would:

1. Connect to the local X server. This requires an active session or the ability to connect over the X protocol.
2. Send a DRI2GetBuffers or DRI2GetBuffersWithFormat request containing multiple DRI2BufferBackLeft attachments and one DRI2BufferFrontLeft attachment.
3. The server processes each attachment entry without deduplication and writes past the end of the heap-allocated buffer array.
4. The heap corruption either crashes the X server (denial of service) or, with careful manipulation of the heap layout, lets the attacker overwrite function pointers or other critical heap metadata.
5. If the X server runs as root, successful heap exploitation gives the attacker root privileges.

CVSS Scoring Divergence

Red Hat's lower score reflects its view that reliable code execution through heap manipulation is non-trivial in practice, because the attacker has to defeat ASLR and modern heap hardening.

Patch Information

The fix for CVE-2026-50264 comes in two commits to the X.Org X server repository. Michel Dänzer authored both, and Peter Hutterer committed them. They shipped in xorg-server 21.1.23 and xwayland 24.1.12 as part of merge request !2228 ("Fix a number of security issues").

Commit 1: Preparatory Refactor (b7aa65cc)

"dri2: Use booleans for (fake) front buffer tracking in do_get_buffers"

This commit converts the vulnerable integer counters into Bool variables:

// AFTER:
Bool need_real_front = FALSE;
Bool have_real_front = FALSE;
Bool need_fake_front = FALSE;
Bool have_fake_front = FALSE;
...
need_real_front = TRUE;   // on DRI2BufferBackLeft
have_real_front = TRUE;   // on DRI2BufferFrontLeft

Booleans remove the counting mismatch that enabled the vulnerability. The later checks got cleaner as well, with if (need_real_front > 0) becoming if (need_real_front && !have_real_front).

Commit 2: Core Security Fix (339c2795)

"dri2: Deduplicate attachments in do_get_buffer"

This commit adds three layers of defense.

Layer 1: Early count validation. The function now rejects requests where the attachment count exceeds the number of valid attachment types:

    if (!pPriv ||
        count > DRI2BufferHiz + 1) {

Layer 2: Per-attachment validation and deduplication with a bitset. The commit adds a new unsigned attachments_bitset = 0. Inside the processing loop, the function validates and records each attachment:

        if (attachment > DRI2BufferHiz)
            goto err_out;

        if (attachments_bitset & (1u << attachment))
            continue;

        attachments_bitset |= 1u << attachment;

Each bit position in the mask represents one DRI2 attachment type. The bitset check catches duplicate attachment types, and continue skips them silently. Skipping them instead of raising a protocol error keeps backward compatibility with clients that might misbehave this way.

Layer 3: Safer allocation sizing. The allocation is now sized by the maximum number of unique attachment types instead of the raw client-provided count:

// BEFORE:
buffers = calloc((count + 1), sizeof(buffers[0]));

// AFTER (with explanatory comment):
/* Since we deduplicate attachments in the buffers array, there cannot be
 * more entries than there are attachments.
 */
buffers = calloc((min(count, DRI2BufferHiz) + 1), sizeof(buffers[0]));

A client can still send a large count, but the allocation is capped at the number of valid distinct attachment types, so over-allocation is no longer exploitable.

The commit also removes the have_real_front and have_fake_front booleans from the first commit. The bitset does double duty, and checks such as !(attachments_bitset & (1u << DRI2BufferFrontLeft)) and (attachments_bitset & (1u << DRI2BufferFakeFrontLeft)) take their place.

Peter Hutterer of Red Hat identified the vulnerability.

Affected Systems and Versions

These components are affected:

• X.Org X server: all versions prior to 21.1.23
• Xwayland: all versions prior to 24.1.12

Any system running the X.Org X server or Xwayland is vulnerable if a local user can connect to the X server and issue DRI2 buffer requests. Systems where the X server runs as root face the highest risk because of the privilege-escalation path.

Distribution-specific fixed versions:

Red Hat lists some older or unsupported product versions as "Will not fix".

Vendor Security History

X.Org has a long record of memory-safety vulnerabilities, which is unsurprising given the age and complexity of the X11 codebase. The project's security advisories page documents CVEs going back to at least 2013. Notable past vulnerabilities include CVE-2013-6462 (a stack buffer overflow via font files) and CVE-2023-1393 (an overlay window use-after-free).

In 2026 alone, X.Org has published two major batches of security advisories. The first, in April 2026, covered CVE-2026-33999 and others (fixed in xorg-server 21.1.22 and xwayland 24.1.10). The second is the current June 2026 batch of nine CVEs, some of which were found through AI-assisted code analysis, as Phoronix reported. That suggests organizations should expect X.Org security patches to keep coming, possibly at a faster pace, as automated analysis tools get better at finding latent flaws in mature C codebases.

The industry's move to Wayland will eventually shrink the X.Org attack surface, but the transition is far from complete. Many enterprise Linux deployments, embedded systems, and legacy configurations still rely on the X.Org X server.

References

• NVD: CVE-2026-50264
• Red Hat CVE Details: CVE-2026-50264
• Red Hat Bugzilla: Bug 2485389
• GitLab Commit: Deduplicate attachments in do_get_buffer (339c2795)
• GitLab Commit: Use booleans for front buffer tracking (b7aa65cc)
• X.Org Security Advisory: June 2026
• Debian Security Tracker: CVE-2026-50264
• RHSA-2026:21715 (RHEL 8)
• RHSA-2026:20590 (RHEL 7 ELS)
• RHSA-2026:19125 (RHEL 10 Xwayland)
• Phoronix: X.Org Server Starts June With Nine New Security Vulnerabilities
• CVEFeed: CVE-2026-50264
• oss-sec Mailing List: X.Org Security Issues
• X.Org Security Advisories
• CISA Known Exploited Vulnerabilities Catalog