• v5.5.3-12 be643d375c

    v5.5.3-12 Stable

    amnesia released this 2026-07-04 04:21:19 +02:00 | 18 commits to main since this release

    protocol7-core 5.5.3-12 (2026-07-03)

    lainos-dbus-bridge ~ dfuzzer audit, AddressSanitizer, and hardening

    Root cause: Systematic pointer type bug throughout the file ~ char[] and char[N]
    variables were being passed as &var to libdbus functions (dbus_message_append_args,
    dbus_message_iter_append_basic) which expect const char **. This caused libdbus to
    abort internally when called with certain inputs, crashing the bridge.

    Crashes found and fixed via dfuzzer:

    • GetSession ~ crashed on malformed string input; fixed by returning hardcoded
      /org/freedesktop/login1/session/1 (correct for single-user system)
    • GetSeat ~ same crash, same fix; returns hardcoded /org/freedesktop/login1/seat/seat0
    • GetUser ~ crashed when called with UID 0; fixed by ignoring caller-supplied UID
      and returning path based on runtime_uid (dynamically detected at startup)
    • ListSessions ~ crashed due to char[] pointer type bug on sid, uname, seat variables
    • ListSeats ~ same pointer type bug on seat variable
    • ListUsers ~ same pointer type bug on uname variable
    • RuntimePath property ~ crashed due to &runtime_path passed directly to libdbus;
      fixed by assigning to const char *rp = runtime_path before passing &rp

    Additional fixes from 5.5.3-5:

    • Removed setuid/setgid/setresuid/setresgid/setgroups from seccomp whitelist
    • Added execve and wait4 to seccomp whitelist (fixes Reboot/PowerOff D-Bus path)
    • Replaced atoi with strtoul in /etc/passwd UID parsing
    • Removed debug fprintf calls from main()

    Risk Context

    The vulnerability was real but the practical danger was low for several compounding reasons:

    Access requirements: To trigger the crash, an attacker needs either a malicious package installed with user consent, or an existing shell running as the logged-in user. Neither is a remote attack vector. An attacker who already has user-level code execution has far more direct ways to cause damage than crashing a session daemon.

    No session interruption: When lainos-dbus-bridge crashes, the desktop session continues running normally. Sway, greetd, and all running applications are unaffected. Only new applications launched after the crash that query logind for the first time would see an issue, and most fail gracefully. The user's work is not interrupted.

    Instant recovery: doas rc-service lainos-dbus-bridge restart fully restores the bridge. No reboot required.

    No escalation path: The bridge runs as nobody with a tight seccomp filter. Even if the crash were somehow turned into code execution rather than a simple abort, the attacker lands in a nobody context with a restricted syscall surface ~ nothing they didn't already have as the logged-in user. There is no privilege escalation path through the bridge.

    The fix still matters: Correct software handles bad input gracefully. The systematic pointer type bug could theoretically have had more serious consequences in untested code paths. And the testing process that found it demonstrates that Protocol 7 takes correctness seriously ~ the code that ships has been put through a real testing process, not just written and deployed.

    Verification

    • dfuzzer 2.6 run against org.freedesktop.login1 ~ Exit status: 0
    • AddressSanitizer + dfuzzer run ~ Exit status: 0, no memory errors detected
    • All methods and properties PASS across Manager, Session, and User interfaces
    • Reboot and PowerOff skipped as destructive (confirmed working ~ Reboot via D-Bus
      caused actual system reboot during testing, confirming the execve fix works)
    • Bridge confirmed running as nobody after reboot
    • seccomp filter confirmed active (/proc//status unreadable even with doas)
    • System boots and desktop session starts correctly after package install
    Downloads