CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

Rust coreutils vulnerability & Ubuntu’s “oxidation” strategy

• Qualys found a race condition in the Rust uutils coreutils rm, shipped by default in Ubuntu 25.10; it could have enabled local root escalation but was mitigated by swapping back to GNU rm.
• Some argue this shows Canonical rushed Rust utilities into production assuming safety because “it’s Rust,” without enough security review.
• Others say new software naturally has more bugs early on; a spike in vulnerabilities is expected and should be judged over a longer time horizon.
• Debate:
  • One side: GNU coreutils has decades of battle‑hardening and relatively few CVEs; replacing it increases current risk.
  • Other side: Rust’s safety model should eventually yield fewer bugs; making uutils the default accelerates that maturation.

Limits of Rust and nature of race conditions

• Several comments stress that Rust cannot prevent all race conditions, especially those across processes, filesystems, or system boundaries.
• Distinction made between “data races” (which safe Rust prevents) and broader logic or TOCTOU races (which any language can suffer).
• Some frustration with overblown “Rust will fix security” narratives; core message: language helps, but system‑level design and programmer discipline are crucial.

Snap, systemd‑tmpfiles, and /tmp design

• Core flaw discussed: a predictable, world‑writable path under /tmp used by a root process (snap-confine with systemd‑tmpfiles cleanup) enables a race for privilege escalation.
• Commenters note similar /tmp timing/permission bugs predate snap/systemd; the underlying pattern is not new.
• Suggested mitigations: user‑specific temp dirs, tighter ownership checks (e.g., open + fstat + *at syscalls), or using /run/user/$UID and private /tmp features that systemd already provides.
• Some ask why snap doesn’t use those safer mechanisms; this is left unclear.

Privilege escalation, suid, and alternatives

• Debate over whether suid should be considered a design mistake and disabled.
• One camp: suid repeatedly leads to local root exploits; prefer privileged daemons plus IPC or tightly scoped sudo rules.
• Counterpoint: any solution still runs code as root; a small, well‑audited suid helper can be safer than complex daemons or large frameworks.

Broader reactions to Snap and distros

• Multiple commenters dislike Snap’s complexity, performance, security surface, and closed distribution story; some disable snapd entirely.
• Alternatives suggested: Debian (often with XFCE), Devuan, Pop!_OS, Fedora, or Arch.
• Some view Snap as contradicting Ubuntu’s earlier values and prefer Flatpak or traditional packaging.