Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
Consider setting dev.tty.ldisc_autoload=0 by default
Reported by drneb99 · filed Aug 31, 2026 · open at source
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
Title: Consider setting dev.tty.ldisc_autoload=0 by default
Body:
Similar in spirit to #9194/#9288 — another Arch default that's a known, low-risk kernel hardening win Omarchy doesn't currently apply.
dev.tty.ldisc_autoload controls whether unprivileged processes can force the kernel to cold-load a TTY line-discipline module on demand, via the TIOCSETD ioctl. Arch ships this as 1 (CONFIG_LDISC_AUTOLOAD=y), so it's on by default on a fresh Omarchy install too.
This has a real history as a local-privilege-escalation surface: rarely-used, rarely-audited line-discipline modules have shipped real CVEs (e.g. n_hdlc / CVE-2017-2636, n_gsm / CVE-2023-6546). The kernel added this sysctl specifically so admins could close that path; KSPP (Kernel Self Protection Project) lists dev.tty.ldisc_autoload=0 in its Recommended Settings with no caveats.
I confirmed this is exploitable on a stock Omarchy 4.0.1 install: as a normal unprivileged user with no special capabilities, a TIOCSETD ioctl on /dev/ptmx forced the kernel to load a module (pps_ldisc, chosen as a benign test target) that wasn't previously resident. CONFIG_N_HDLC=m is present on this kernel, meaning the CVE-2017-2636 module is reachable through the same primitive.
Setting it to 0 only blocks the unprivileged, on-demand loading path — root/systemd/udev module loading at boot is unaffected (verified in drivers/tty/tty_ldisc.c: the check is gated behind !capable(CAP_SYS_MODULE)), so tools like btattach/ldattach/pppd (which run as root) keep working normally.
One honest caveat: a daemon that drops root privileges and then tries to attach a line discipline (the classic example is gpsd doing PPS timing via pps_ldisc) would break. The workaround is trivial — pre-load the needed module once via /etc/modules-load.d/, after which unprivileged TIOCSETD for that already-loaded module succeeds normally. Not a reason to hold this back, just worth knowing.
Proposed change, same shape as #9288:
etc/sysctl.d/99-omarchy-sysctl.conf:
# Stop unprivileged processes from autoloading obscure TTY line-discipline
# modules via TIOCSETD, a recurring local privilege-escalation surface
# (n_hdlc/CVE-2017-2636, n_gsm/CVE-2023-6546). Root, systemd and udev still
# autoload normally, so btattach/ldattach/pppd are unaffected.
dev.tty.ldisc_autoload=0Plus a migration (matching the 1788139000.sh pattern from #9288) so existing installs get the runtime value applied immediately rather than waiting for reboot.
Note on sequencing: #9288 is still open and touches the same file/region, so whichever of these two lands second will need a small rebase — flagging so it doesn't cause merge friction.
Happy to open a PR for this if useful, similar to how #9288 was done for the kptr_restrict issue.
System info: Omarchy 4.0.1 (BUILD_ID 4.0.1), kernel 7.1.9-arch1-2
View raw text
Title: Consider setting dev.tty.ldisc_autoload=0 by default Body: Similar in spirit to #9194/#9288 — another Arch default that's a known, low-risk kernel hardening win Omarchy doesn't currently apply. `dev.tty.ldisc_autoload` controls whether *unprivileged* processes can force the kernel to cold-load a TTY line-discipline module on demand, via the `TIOCSETD` ioctl. Arch ships this as `1` (`CONFIG_LDISC_AUTOLOAD=y`), so it's on by default on a fresh Omarchy install too. This has a real history as a local-privilege-escalation surface: rarely-used, rarely-audited line-discipline modules have shipped real CVEs (e.g. `n_hdlc` / CVE-2017-2636, `n_gsm` / CVE-2023-6546). The kernel added this sysctl specifically so admins could close that path; KSPP (Kernel Self Protection Project) lists `dev.tty.ldisc_autoload=0` in its Recommended Settings with no caveats. I confirmed this is exploitable on a stock Omarchy 4.0.1 install: as a normal unprivileged user with no special capabilities, a `TIOCSETD` ioctl on `/dev/ptmx` forced the kernel to load a module (`pps_ldisc`, chosen as a benign test target) that wasn't previously resident. `CONFIG_N_HDLC=m` is present on this kernel, meaning the CVE-2017-2636 module is reachable through the same primitive. Setting it to `0` only blocks the *unprivileged, on-demand* loading path — root/systemd/udev module loading at boot is unaffected (verified in `drivers/tty/tty_ldisc.c`: the check is gated behind `!capable(CAP_SYS_MODULE)`), so tools like `btattach`/`ldattach`/`pppd` (which run as root) keep working normally. **One honest caveat:** a daemon that drops root privileges and *then* tries to attach a line discipline (the classic example is `gpsd` doing PPS timing via `pps_ldisc`) would break. The workaround is trivial — pre-load the needed module once via `/etc/modules-load.d/`, after which unprivileged `TIOCSETD` for that already-loaded module succeeds normally. Not a reason to hold this back, just worth knowing. **Proposed change**, same shape as #9288: `etc/sysctl.d/99-omarchy-sysctl.conf`: ``` # Stop unprivileged processes from autoloading obscure TTY line-discipline # modules via TIOCSETD, a recurring local privilege-escalation surface # (n_hdlc/CVE-2017-2636, n_gsm/CVE-2023-6546). Root, systemd and udev still # autoload normally, so btattach/ldattach/pppd are unaffected. dev.tty.ldisc_autoload=0 ``` Plus a migration (matching the `1788139000.sh` pattern from #9288) so existing installs get the runtime value applied immediately rather than waiting for reboot. **Note on sequencing:** #9288 is still open and touches the same file/region, so whichever of these two lands second will need a small rebase — flagging so it doesn't cause merge friction. Happy to open a PR for this if useful, similar to how #9288 was done for the kptr_restrict issue. System info: Omarchy 4.0.1 (BUILD_ID 4.0.1), kernel 7.1.9-arch1-2
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 10:13 UTC