X.Org X server CVE-2026-93522

Exploitation requires the attacker to already be a connected, authenticated X client on the target X server or Xwayland instance - i.e. local access to an active X session (default on traditional Linux desktops using a local Unix-domain socket), not remote network access unless the server is explicitly configured to listen on TCP (non-default). Based on the inferred glamor/glamor_transfer.c fix, the vulnerable path (glamor_upload_boxes) additionally requires the glamor GPU-acceleration backend to be in use and a specific drawable/pixmap depth mismatch (24-bit drawable on a 32-bit pixmap) combined with dimensions large enough to overflow the size computation, so headless servers, non-glamor configurations, and small/ordinary rendering operations are not affected. LIMITING FACTORS: authenticated local X client required, glamor acceleration path required, and large/crafted dimensions needed to trigger the overflow - these conditions meaningfully narrow realistic exploitation. Note: because the exact CVE-2026-93522 description was truncated from the input, confirm these conditions against the full vendor advisory.

No CVSS vector, EPSS, KEV, or POC signal was provided for CVE-2026-93522, so quantitative risk signals are entirely absent and must be inferred from the X.Org advisory context and the linked source diffs. CRITICAL CAVEAT: the provided advisory text is truncated at CVE-2026-93520 and never reaches CVE-2026-93522's own paragraph, so the exact vulnerability description for THIS CVE is MISSING from the input - the analysis below is reconstructed from Linked article 2 (a glamor/glamor_transfer.c integer-overflow fix adding an INT_MAX/byte_stride guard in glamor_upload_boxes), which is the most likely match but is NOT independently confirmed to map to CVE-2026-93522. Across the entire advisory batch, every issue shares the same core risk profile: exploitation requires an already-authenticated/connected X client (local, low-privilege), and the memory-safety bug (here an integer overflow producing an undersized heap allocation followed by an out-of-bounds write) can yield denial of service or potentially arbitrary code execution in the X server process, which frequently runs with elevated or root privileges on traditional Linux desktops. This is a genuine local privilege-escalation / display-server-compromise class issue rather than a remote mass-exploitation threat: the authentication-and-local-client prerequisite substantially limits real-world weaponization, so it is a meaningful priority for multi-user and desktop hardening but not an internet-facing emergency. No signals conflict because none are present; the dominant uncertainty is data completeness, not signal disagreement.

A local, authenticated user (or a malicious/compromised application running under a user's X session) connects to the X server as a normal client and issues a crafted image-upload/rendering request that triggers an integer overflow in glamor's buffer-size calculation, producing an undersized heap allocation that is then overwritten. This corrupts X server heap memory, crashing the display server (DoS) or potentially allowing code execution in the X server context, which is often privileged. No public exploit was provided in the input; the issue was reported through Trend/ZDI (ZDI-CAN series) with vendor source-code fixes.