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-819GitHub issuePublicDecided· Out of scope

Public kernel LPE targeting Omarchy (vxlan FDB flush UAF) — fix queued in stable, no Arch kernel release carries it yet

Reported by alvarofraguas · filed Sep 8, 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

Public kernel LPE targeting Omarchy (vxlan FDB flush UAF) — fix queued in stable, no Arch kernel release carries it yetrevision 1 · captured 2026-09-28 21:23 UTC via poll

Context

On 2026-09-06, blasty published two exploits against Omarchy:

  • omarchy-kitty-pwn.py (kitty escape-sequence RCE) — already addressed by #10527 / PR #10605 (allow_remote_control socket-only + migration). Thank you for the fast turnaround there.
  • blasty-vs-omarchy.c — a local privilege escalation. This is not an Omarchy bug: it races a vxlan FDB flush use-after-free in the Linux kernel (veth/vxlan/netns topology built from an unprivileged user namespace, bulk NDA_PORT-filtered FDB flush with RTNLGRP_NEIGH listeners widening the destroy-notify window, KASLR defeated via a futex side-channel, then modprobe_path overwrite via binfmt autoload).

The upstream fix exists but hasn't reached any released kernel

  • Root-cause fix: `d5d4a7b5` — "vxlan: keep the last remote linked during FDB flush" (Kyle Zeng / David Lee, Trail of Bits; Cc: stable), merged into netdev net 2026-08-17. Bug was introduced in 2023 by c499fccb71cb ("vxlan: vxlan_core: Support FDB flushing by destination VNI").
  • Related UAF fixes in the same stable queue: vxlan: mdb: Fix use-after-free in vxlan_mdb_flush(), vxlan: mdb: Fix use-after-free in vxlan_mdb_remote_src_del(), vxlan: fix reading neigh ha.
  • The fix is backported to both linux-7.1.y and linux-7.2.y but is queued after v7.1.11 / v7.2.4 — i.e. it lands in v7.1.12 / v7.2.5.
  • No CVE has been assigned and the Arch Security Tracker has no vxlan entry, so this can slip past release-monitoring.
  • core/linux as of today (7.2.3/7.2.4) does not contain the fix.

What this issue could track

  1. Flag the next linux stable bump (7.2.5 / 7.1.12) as the point release that closes this LPE, and surface it in the update flow so users know to reboot.
  2. Consider whether Omarchy wants a documented interim mitigation note: the exploit's first stage requires unprivileged user namespaces (sysctl user.max_user_namespaces=0 blocks it, with the usual bubblewrap/flatpak/container tradeoffs).
  3. Note that kernel.kptr_restrict=1 (PR #9288) does not mitigate this particular exploit — KASLR is defeated via the futex side-channel, not /proc — so that hardening shouldn't be presented as coverage for this one.

Happy to help verify once 7.2.5 ships in core.

View raw text
**Context**

On 2026-09-06, blasty published two exploits against Omarchy:

- `omarchy-kitty-pwn.py` (kitty escape-sequence RCE) — **already addressed** by #10527 / PR #10605 (`allow_remote_control socket-only` + migration). Thank you for the fast turnaround there.
- `blasty-vs-omarchy.c` — a local privilege escalation. **This is not an Omarchy bug**: it races a vxlan FDB flush use-after-free in the Linux kernel (veth/vxlan/netns topology built from an unprivileged user namespace, bulk `NDA_PORT`-filtered FDB flush with `RTNLGRP_NEIGH` listeners widening the destroy-notify window, KASLR defeated via a futex side-channel, then `modprobe_path` overwrite via binfmt autoload).

**The upstream fix exists but hasn't reached any released kernel**

- Root-cause fix: [`d5d4a7b5`](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d5d4a7b538b52db63927773a8905fcd9f78a42e2) — *"vxlan: keep the last remote linked during FDB flush"* (Kyle Zeng / David Lee, Trail of Bits; `Cc: stable`), merged into netdev net 2026-08-17. Bug was introduced in 2023 by `c499fccb71cb` (*"vxlan: vxlan_core: Support FDB flushing by destination VNI"*).
- Related UAF fixes in the same stable queue: `vxlan: mdb: Fix use-after-free in vxlan_mdb_flush()`, `vxlan: mdb: Fix use-after-free in vxlan_mdb_remote_src_del()`, `vxlan: fix reading neigh ha`.
- The fix is backported to both `linux-7.1.y` and `linux-7.2.y` but is queued **after** `v7.1.11` / `v7.2.4` — i.e. it lands in **v7.1.12 / v7.2.5**.
- No CVE has been assigned and the Arch Security Tracker has no vxlan entry, so this can slip past release-monitoring.
- `core/linux` as of today (7.2.3/7.2.4) does **not** contain the fix.

**What this issue could track**

1. Flag the next `linux` stable bump (7.2.5 / 7.1.12) as the point release that closes this LPE, and surface it in the update flow so users know to reboot.
2. Consider whether Omarchy wants a documented interim mitigation note: the exploit's first stage requires unprivileged user namespaces (`sysctl user.max_user_namespaces=0` blocks it, with the usual bubblewrap/flatpak/container tradeoffs).
3. Note that `kernel.kptr_restrict=1` (PR #9288) does **not** mitigate this particular exploit — KASLR is defeated via the futex side-channel, not `/proc` — so that hardening shouldn't be presented as coverage for this one.

Happy to help verify once 7.2.5 ships in `core`.

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 11:10 UTC