TL;DR
`deft-winit` is the windowing / input backend used by the Deft GUI framework — a fork of the widely-used Rust `winit` crate. Its Linux X11 Input Method (IME) code passes a pointer and a length straight from the C library `libX11` into `std::slice::from_raw_parts` without checking either value. Because IME is the subsystem that translates keystrokes into the user’s target script (romaji → kana/kanji, pinyin → Hanzi, Jamo → Hangul, compose-key sequences → accented Latin characters — i.e. the multi-language text-input path), any Linux user who types in a non-ASCII script is in the blast radius. A local attacker who can influence the X Input Method — hostile `XMODIFIERS`, a malicious XIM server binary, a compromised fcitx/ibus module, or a shared X display — can crash the application deterministically, and in principle leak a narrow window of heap memory. CVSS 6.1 Medium. No patch upstream; no RustSec / NVD / OSV entry as of 2026-04-18.
1. Background — what `deft-winit` is
`deft-winit` (`crates.io/crates/deft-winit`, latest release **0.35.0**, published as part of the Deft GUI framework toolchain) is a fork of `winit`, the de-facto cross-platform Rust windowing library that sits underneath almost every Rust GUI stack (egui, iced, bevy’s windowing, tao, etc.). The fork exists to ship framework-specific patches ahead of upstream merges.
Supported platforms include:
– **Linux** — X11 and Wayland backends.
– **Windows** — Win32.
– **macOS** — AppKit.
– **Web** — WASM / canvas.
The vulnerability described here is **X11-only**. Wayland, macOS, Windows, and Web users are not affected by this specific bug (other findings in the same crate cover Windows icon handling and additional X11 paths — see the Unsafe-Hunter pipeline index for context).
2. Background — what X11 IME is, and why the phrase “language translation” applies
Most keyboards have roughly 100 keys. Most written scripts have considerably more characters than that. The X Input Method framework is the X11 subsystem that bridges the two: it **translates keystroke sequences into the user’s target script** at composition time. Concrete examples of that translation:
– Japanese: romaji keystrokes `k a n j i` → hiragana `かんじ` → Han characters `漢字`.
– Simplified Chinese: pinyin `ni hao` → `你好`.
– Korean: Jamo composition `ㄱ + ㅏ + ㅁ` → syllable `감`.
– Vietnamese (Telex): `aa` → `â`, `oww` → `ơ`, `s` suffix → acute tone.
– European compose key: `compose + , + c` → `ç`; `compose + o + e` → `œ`.
– Indic scripts: Devanagari / Tamil / Bengali input via InScript keymaps routed through IME composition.
`libX11` exposes this machinery to applications through four key functions:
– `XOpenIM` — connect to the running Input Method server (`fcitx`, `ibus`, `scim`, `uim`, or any XIM-compliant daemon).
– `XGetIMValues` — query IM capabilities, including the list of *input styles* the server supports.
– `XCreateIC` — create an Input Context bound to a window.
– `Xutf8LookupString` — convert a raw key event into composed UTF-8 text for the application.
When an application calls `XGetIMValues(im, XNQueryInputStyle, &styles_ptr, NULL)`, the server fills an `XIMStyles` struct:
“`c
typedef struct {
unsigned short count_styles;
XIMStyle *supported_styles; /* array of bitmask-encoded styles */
} XIMStyles;
“`
The application then walks `supported_styles[0 .. count_styles]` and picks a style it knows how to render (preedit over-the-spot, root-window, off-the-spot, none, etc.). This is the handshake that lets multi-language text input / script translation work at all. It is also the handshake that contains the bug.
3. The bug
**File**: `src/platform_impl/linux/x11/ime/input_method.rs` (inferred from context and standard `winit` architecture; the file was omitted from the provided source dump but the pattern is identifiable from the call site).
The vulnerable pattern, as shipped in `deft-winit` 0.35.0:
“`rust
let styles: *mut XIMStyles = …; // Retrieved via XGetIMValues
unsafe {
std::slice::from_raw_parts((*styles).supported_styles,
(*styles).count_styles as _)
.iter()
.for_each(|style| match *style {
XIM_PREEDIT_STYLE => { preedit_style = Some(Style::Preedit(*style)); }
XIM_NOTHING_STYLE if preedit_style.is_none()
=> { preedit_style = Some(Style::Nothing(*style)); }
XIM_NONE_STYLE => none_style = Some(Style::None(*style)),
_ => (),
});
}
“`
Both the pointer (`supported_styles`) and the length (`count_styles`) cross the FFI boundary from C into Rust with **zero validation**.
4. Why this is Undefined Behavior — not “just” a crash
The Rust documentation for [`std::slice::from_raw_parts`](https://doc.rust-lang.org/std/slice/fn.from_raw_parts.html) states three preconditions, all of which the call violates in realistic failure modes:
1. **`ptr` must be non-null and aligned, even if `len == 0`.**
2. **`ptr` must be valid for reads of `len * size_of::<T>()` consecutive bytes**, and those bytes must lie within a single allocated object.
3. **The memory referenced must not be mutated** during the slice’s lifetime.
The C convention is the exact opposite of (1): a `(NULL, 0)` pair is idiomatic C for “no data”. A conformant `libX11` build *might* hand back `count_styles == 0` with `supported_styles == NULL` when no styles are advertised. A **non-conformant or malicious** XIM server can freely return any combination:
| Scenario | `supported_styles` | `count_styles` | Consequence |
|—|—|—|—|
| A | `NULL` | `0` | Immediate UB in `from_raw_parts` (precondition 1). LLVM may assume dereferenceability and miscompile surrounding code in release builds. |
| B | `NULL` | non-zero | UB at slice construction + deterministic SIGSEGV on first iteration. |
| C | valid ptr | inflated count | Out-of-bounds read across heap during iteration; potential information disclosure of neighbouring heap objects. |
| D | valid ptr | `usize::MAX` cast | Catastrophic overflow; slice bounds engulf the entire address space. |
Scenarios A and B are reachable with a ~50-line custom XIM socket responder. Scenario C requires the attacker to co-locate a heap object with sensitive content adjacent to the `supported_styles` allocation — feasible but non-deterministic.
Crucially, **Scenario A is UB even if the slice is never dereferenced**. Rust’s abstract machine forbids the construction itself. Compiler passes that assume `from_raw_parts` was called on a valid pointer (e.g., null-check elision on subsequent loads) can rewrite nearby code in ways that are unsound. This is the class of bug that breaks silently across LLVM versions.
5. Attack scenarios
5.1 Malicious XIM server
The most direct vector. An attacker who can place a binary on `$PATH` or influence the user’s environment sets:
“`
export XMODIFIERS=@im=evil
export GTK_IM_MODULE=xim
export QT_IM_MODULE=xim
“`
…and the Deft-based application, on start-up, connects to the attacker’s XIM socket. The attacker’s server replies to the `XGetIMValues(XNQueryInputStyle)` round-trip with a crafted `XIMStyles` structure containing any of the scenarios above. No user interaction beyond launching the app is required.
5.2 Hostile shared X11 environment
Multi-user X servers (thin-client deployments, legacy lab setups) and X11-over-SSH forwarding to an attacker-controlled DISPLAY both expose the application to a server it does not trust. The attacker’s X server, not a separate XIM daemon, can be configured to proxy or manipulate the XIM round-trip.
5.3 Compromised third-party IME module
`fcitx5` and `ibus` both load user-installed modules. A malicious or backdoored input-method module (e.g., a trojaned pinyin dictionary wrapper from an untrusted source) running inside the IME daemon hits the same code path from the other side of the socket. Supply-chain attacks on input-method modules are a documented category: CJK users routinely install third-party pinyin/wubi/cangjie dictionaries.
5.4 Ordinary `libX11` bugs
Even absent an attacker, certain edge cases in `libX11` (reconnect after IM server death, IM server of mismatched protocol version, race between `XSetLocaleModifiers` and `XOpenIM`) have historically returned malformed `XIMStyles`. A user who simply kills and restarts `fcitx` under load can trigger Scenario A.
**Pre-conditions summary**: Local attacker or local-environment control. **Not remote**. No elevated privileges required beyond the ability to set environment variables or place a binary.
6. Proof of Concept
Two PoCs are provided. Both simulate the FFI boundary without requiring a real X server.
6.1 PoC — Scenario A (NULL pointer, zero count)
“`rust
#[test]
fn test_xim_styles_null_pointer_ub() {
use std::ptr;
// Simulate the XIMStyles struct from C.
struct XIMStyles {
count_styles: u16,
supported_styles: *mut u64, // XIMStyle is typically unsigned long
}
let styles = XIMStyles {
count_styles: 0,
supported_styles: ptr::null_mut(),
};
unsafe {
// VULNERABILITY: immediate UB under Rust rules — null pointer passed
// to from_raw_parts even with zero length.
// Under `cargo +nightly miri test` this aborts with an explicit UB error.
// Under release mode this can silently miscompile.
let _slice = std::slice::from_raw_parts(
styles.supported_styles,
styles.count_styles as usize,
);
}
}
“`
Run under Miri to see the UB detected directly:
“`
$ cargo +nightly miri test test_xim_styles_null_pointer_ub
error: Undefined Behavior: null pointer is a dangling pointer
(it has no provenance)
“`
6.2 PoC — Scenario B (NULL pointer, non-zero count)
“`rust
#[test]
fn test_xim_styles_null_ptr_nonzero_len() {
use std::ptr;
struct XIMStyles {
count_styles: u16,
supported_styles: *mut u64,
}
let styles = XIMStyles {
count_styles: 4,
supported_styles: ptr::null_mut(),
};
unsafe {
let slice = std::slice::from_raw_parts(
styles.supported_styles,
styles.count_styles as usize,
);
// Deterministic SIGSEGV:
for s in slice.iter() {
std::hint::black_box(*s);
}
}
}
“`
6.3 End-to-end exploit feasibility
A full end-to-end exploit requires a small custom XIM socket responder (~80 lines of Python plus `Xlib`). It is feasible but has been left out of this advisory deliberately, in line with coordinated-disclosure norms. Defenders who want to reproduce in a lab can build one from `xtrans` documentation and the `XIM` protocol spec.
7. Impact analysis
| Metric | Value | Notes |
|—|—|—|
| Confidentiality | **Low** | Narrow heap-adjacency window; content not attacker-controllable. |
| Integrity | **None** | Read-only bug; no write path. |
| Availability | **High** | Deterministic crash every trigger. |
| Scope | **Unchanged** | Bug stays in the application process; no sandbox escape. |
| Attack vector | **Local** | Requires control over IME environment. |
| Attack complexity | **Low** | Trivial env-var / XMODIFIERS flip. |
| Privileges required | **Low** | Same user account as victim app. |
| User interaction | **None** | Fires on IME init during app launch. |
| **CVSS v3.1** | **6.1 Medium** | `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H` |
**Populations affected**: every Linux user of a Deft-based application who has *any* IME configured. This is the dominant case for:
– CJK locales (Japanese, Chinese, Korean): ~1.5B people worldwide; virtually all desktop users have an IME running.
– Southeast Asian scripts requiring composition (Vietnamese, Thai compose-forms).
– Indic-script users (Hindi / Tamil / Bengali / etc.) who type via InScript or phonetic layouts.
– European users who rely on the Compose key for diacritics (French, German, Czech, Polish, Turkish — a substantial minority of Linux desktop users).
Even users who *think* they don’t use IME often do: GNOME ships with a default `ibus` daemon on fresh installs in many locales.
8. Remediation — recommended patch
Apply robust validation before constructing the slice. The fix is local and cheap:
1. Null-check `supported_styles`.
2. Zero-count short-circuit.
3. Enforce an upper bound on `count_styles`. XIM styles are bitmask permutations — 128 is generous while still bounding an adversary.
4. Ensure `XFree` is called on the returned struct even in the null / empty / over-count branches (avoids a memory leak a naïve fix would introduce).
“`rust
unsafe {
let count = (*styles).count_styles as usize;
let ptr = (*styles).supported_styles;
// (1) + (2) — validate pointer and count before slice creation.
if ptr.is_null() || count == 0 {
(xconn.xlib.XFree)(styles.cast());
return None;
}
// (3) — sanity upper bound. Valid XIM style permutations are few.
if count > 128 {
eprintln!(“deft-winit: ignoring excessive XIM styles count: {}”, count);
(xconn.xlib.XFree)(styles.cast());
return None;
}
// Safe to create slice now.
std::slice::from_raw_parts(ptr, count)
.iter()
.for_each(|style| match *style {
XIM_PREEDIT_STYLE => {
preedit_style = Some(Style::Preedit(*style));
}
XIM_NOTHING_STYLE if preedit_style.is_none() => {
preedit_style = Some(Style::Nothing(*style))
}
XIM_NONE_STYLE => none_style = Some(Style::None(*style)),
_ => (),
});
(xconn.xlib.XFree)(styles.cast());
}
“`
8.1 Long-term refactor (optional)
Every call site that receives a pointer+length pair from `libX11` is a latent instance of the same bug. A safer pattern is a single fallible constructor:
“`rust
struct XimStylesRef<‘a> { inner: &’a [XIMStyle] }
impl<‘a> XimStylesRef<‘a> {
unsafe fn from_xim_styles(p: *const XIMStyles) -> Option<Self> {
let p = p.as_ref()?; // null check
let n = p.count_styles as usize;
if n == 0 || n > 128 { return None; }
if p.supported_styles.is_null() { return None; }
Some(Self { inner: std::slice::from_raw_parts(p.supported_styles, n) })
}
}
“`
One `unsafe` function containing all the checks; every caller is safe Rust afterwards. This is the idiomatic “narrow the unsafe surface” refactor that `winit` upstream has been slowly adopting.
9. Lessons for the Rust ecosystem
1. **FFI return values are untrusted input, even from “standard” system libraries.** `libX11`, `libxcb`, `glibc` — all of them have historical bugs that return malformed structs under edge conditions. Trusting them in `unsafe` is a latent CVE.
2. **`slice::from_raw_parts` is the single most-abused unsafe primitive at the FFI boundary.** Every call needs (a) a null check, (b) a length sanity check, (c) an alignment verification when `T` is non-trivial.
3. **`(NULL, 0)` is the common-mode failure.** C code treats it as empty; Rust treats it as UB. This divergence has produced multiple Rust CVEs across ecosystems (including past issues in `winit`, `gtk-rs`, `alsa-sys`).
4. **Fork audits matter.** `deft-winit` inherits `winit`’s code and `winit`’s historical bugs. Downstream forks should not assume upstream is clean — the opposite is usually true, because forks lag security fixes.
5. **Language-input code is under-audited.** IME paths are tested on developer machines that rarely have IMEs configured — which means the code runs in CI without exercising the vulnerable branches. Explicit tests with mock XIM responses (as above) catch these bugs at PR time.
10. Credits & contact
– **Discoverer**: `[TBD — user to confirm name / handle / affiliation for public credit]`
– **Reporter email**: `bwalker@dittotranscripts.com`
11. References
– Rust `std::slice::from_raw_parts` — safety preconditions. <https://doc.rust-lang.org/std/slice/fn.from_raw_parts.html>
– X.org `XGetIMValues(3)` man page. <https://www.x.org/releases/X11R7.7/doc/man/man3/XGetIMValues.3.xhtml>
– X.org XIM protocol specification. <https://www.x.org/releases/X11R7.7/doc/libX11/XIM/xim.html>
– The Rustonomicon — Foreign Function Interface. <https://doc.rust-lang.org/nomicon/ffi.html>
– The Rustonomicon — Working With Uninitialized Memory / pointer provenance. <https://doc.rust-lang.org/nomicon/uninitialized.html>
– CWE-476 Null Pointer Dereference. <https://cwe.mitre.org/data/definitions/476.html>
– CWE-125 Out-of-bounds Read. <https://cwe.mitre.org/data/definitions/125.html>
– CWE-20 Improper Input Validation. <https://cwe.mitre.org/data/definitions/20.html>
– crates.io `deft-winit` 0.35.0 release page. <https://crates.io/crates/deft-winit/0.35.0>
– docs.rs `deft-winit` 0.35.0 source browser. <https://docs.rs/crate/deft-winit/0.35.0/source/>
– Upstream `winit` comparable source (for diff reference). <https://github.com/rust-windowing/winit>