X.Org X Server CVE-2026-88812

Requires an authenticated X client - i.e. an attacker-controlled process already able to open a connection to the target X.Org X server or Xwayland instance (typically local to the display session). The specific trigger is an XkbSetGeometry request carrying a malformed TextDoodad entry crafted to force the _CheckSetDoodad() error path; the XKB extension handling this request is standard and enabled by default. Limiting factors: exploitation is not remote or unauthenticated - it presupposes existing access to the X display, so it is primarily a local privilege/sandbox-escape or same-session corruption vector; reliable code execution (versus a crash) additionally depends on defeating heap allocator hardening. Affected only on versions prior to xorg-server-21.1.25 and xwayland-24.1.14.

No CVSS vector, EPSS score, KEV entry, or public POC is present in the supplied data, so quantitative exploitation signals are entirely absent and must be stated as unknown rather than inferred. Qualitatively, this is a double free in _CheckSetDoodad() (xkb/xkb.c): the error path frees doodad->text.text without NULLing it, and _XkbClearDoodad() frees it again during cleanup, yielding heap corruption that the advisory says may enable arbitrary code execution or a crash. Exploitation requires an authenticated X client (a connection to the X server / Xwayland), which points to a local, not network-facing, threat model - on most deployments the X server runs within the user's session, though on some legacy configurations it runs as root, which would raise impact. The flaw was reported through Trend/ZDI (ZDI-CAN-31221) by an anonymous researcher, indicating a credible, triaged finding, but ZDI reporting is not evidence of in-the-wild exploitation. Net assessment: a genuine memory-corruption vulnerability worth patching on multi-user or sandboxed-GUI systems, but absent EPSS/KEV/POC data it is not demonstrably under active exploitation, and real-world risk is bounded by the requirement for an already-authenticated local X client. Reliable double-free-to-code-execution against modern hardened heap allocators is non-trivial, so denial of service is the more probable practical outcome.

A local, already-authenticated X client (for example a malicious or compromised application in a desktop or multi-user session) sends a crafted XkbSetGeometry request containing a malformed TextDoodad entry that forces the initial error path in _CheckSetDoodad(). The freed-but-not-NULLed doodad->text.text pointer is freed a second time during _XkbClearDoodad() cleanup, corrupting the heap to crash the server or, with careful heap grooming, attempt arbitrary code execution in the X server's context. No public exploit was identified in the provided data; the issue was reported privately via Trend/ZDI (ZDI-CAN-31221).