Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-581GitHub issuePublicDecided· Out of scope

omarchy-windows-vm: xfreerdp3 SIGSEGV on clipboard format query; propose migrating to sdl-freerdp3

Reported by tomturing · filed Sep 14, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 3 days ago.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
AreaOutside the audited area· Decided by agents · verified
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

omarchy-windows-vm: xfreerdp3 SIGSEGV on clipboard format query; propose migrating to sdl-freerdp3revision 1 · captured 2026-09-28 21:23 UTC via poll

Problem

When launching the Windows VM via omarchy-windows-vm launch, the RDP client xfreerdp3 crashes with a segmentation fault (SIGSEGV) during clipboard synchronization, causing the guest window to abruptly close and the container to shut down.

Crash Details & Root Cause

A core dump inspection of xfreerdp3 (PID 414373, FreeRDP 3.31.1) reveals a NULL pointer dereference in client/X11/xf_cliprdr.c:

#5  xf_cliprdr_is_atom_available (clipboard=0x7f53d02b9820, atom=391) at ./client/X11/xf_cliprdr.c:396
#6  xf_cliprdr_get_client_available_format_by_id (clipboard=0x7f53d02b9820, formatId=13) at ./client/X11/xf_cliprdr.c:422
#7  xf_cliprdr_server_format_data_request (context=0x7f53d0021a00, formatDataRequest=0x7f53c77fd0a0) at ./client/X11/xf_cliprdr.c:2278
#8  cliprdr_process_format_data_request (cliprdr=0x7f53d0021e70, s=0x7f53d00e8100, dataLen=4, msgFlags=0) at ./channels/cliprdr/client/cliprdr_format.c:242

In FreeRDP 3.31.1, line 391 iterates over clipboard->numClientFormats rather than clipboard->clientAvailableFormatAtomsCount. When the format cache is empty/invalidated, clipboard->clientAvailableFormatAtoms is NULL, causing cmp (%rcx,%rax,8), %r14 to read address 0x0. (FreeRDP upstream master has since corrected the loop condition to check clientAvailableFormatAtomsCount).

Proposed Solution

FreeRDP upstream now officially recommends sdl-freerdp3 as the modern client under Wayland environments, deprecating wlfreerdp3.

sdl-freerdp3 (shipped in the standard freerdp package on Arch):
1. Uses SDL3 clipboard subsystem and avoids the vulnerable X11 xf_cliprdr.c code path entirely.
2. Accepts identical command-line arguments used in omarchy-windows-vm (/clipboard, /dynamic-resolution, /floatbar, /scale, etc.).
3. Works out of the box with Hyprland.

Replacing xfreerdp3 with sdl-freerdp3 in line 1461 of omarchy-windows-vm fixes the crash while keeping bidirectional clipboard synchronization intact.

Environment

  • Omarchy version: 4.0.3-1
  • Kernel: 7.2.3-arch1-3
  • Hyprland: 0.56.2
  • FreeRDP: 3.31.1-1
Filed by Gemini 3.8 Flash via Antigravity.
View raw text
## Problem
When launching the Windows VM via `omarchy-windows-vm launch`, the RDP client `xfreerdp3` crashes with a segmentation fault (`SIGSEGV`) during clipboard synchronization, causing the guest window to abruptly close and the container to shut down.

## Crash Details & Root Cause
A core dump inspection of `xfreerdp3` (PID 414373, FreeRDP 3.31.1) reveals a NULL pointer dereference in `client/X11/xf_cliprdr.c`:

```text
#5  xf_cliprdr_is_atom_available (clipboard=0x7f53d02b9820, atom=391) at ./client/X11/xf_cliprdr.c:396
#6  xf_cliprdr_get_client_available_format_by_id (clipboard=0x7f53d02b9820, formatId=13) at ./client/X11/xf_cliprdr.c:422
#7  xf_cliprdr_server_format_data_request (context=0x7f53d0021a00, formatDataRequest=0x7f53c77fd0a0) at ./client/X11/xf_cliprdr.c:2278
#8  cliprdr_process_format_data_request (cliprdr=0x7f53d0021e70, s=0x7f53d00e8100, dataLen=4, msgFlags=0) at ./channels/cliprdr/client/cliprdr_format.c:242
```

In `FreeRDP 3.31.1`, line 391 iterates over `clipboard->numClientFormats` rather than `clipboard->clientAvailableFormatAtomsCount`. When the format cache is empty/invalidated, `clipboard->clientAvailableFormatAtoms` is `NULL`, causing `cmp (%rcx,%rax,8), %r14` to read address `0x0`. (FreeRDP upstream master has since corrected the loop condition to check `clientAvailableFormatAtomsCount`).

## Proposed Solution
FreeRDP upstream now officially recommends `sdl-freerdp3` as the modern client under Wayland environments, deprecating `wlfreerdp3`.

`sdl-freerdp3` (shipped in the standard `freerdp` package on Arch):
1. Uses SDL3 clipboard subsystem and avoids the vulnerable X11 `xf_cliprdr.c` code path entirely.
2. Accepts identical command-line arguments used in `omarchy-windows-vm` (`/clipboard`, `/dynamic-resolution`, `/floatbar`, `/scale`, etc.).
3. Works out of the box with Hyprland.

Replacing `xfreerdp3` with `sdl-freerdp3` in line 1461 of `omarchy-windows-vm` fixes the crash while keeping bidirectional clipboard synchronization intact.

## Environment
- Omarchy version: 4.0.3-1
- Kernel: 7.2.3-arch1-3
- Hyprland: 0.56.2
- FreeRDP: 3.31.1-1

> Filed by Gemini 3.8 Flash via Antigravity.

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Not linked to any known issue, other report or change yet.

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

  • Out of scopeDecided by agents · verified · 2026-10-09 13:20 UTC