CVE-2026-35341

When `mkfifo()` fails (e.g. target already exists), the code shows an error but is missing a `continue;`, so it falls through to `fs::set_permissions` and changes the permissions of the pre-existing file to the default FIFO mode (`0o666` & umask -> `0644`). ``` $ touch secret; chmod 000 secret $ coreutils mkfifo secret fifo3 fifo4 mkfifo: cannot create fifo 'secret': File exists $ ll secret # uutils: prw-r--r-- secret # changed to 644 (GNU leaves it 000) ``` **Impact:** an attacker (or user error) can relax permissions on sensitive owner-only files such as SSH private keys, exposing them to other users. Recommendation: add `continue;` after the error. **Remediation:** Acknowledged by Canonical; fixed in PR #10376. --- _Reported by Zellic in the *uutils coreutils Program Security Assessment* (prepared for Canonical, Jan 20 2026), audited commit `3a07ffc5a9bd4c283e75afa548ba1f1957bad242`. Finding 3.8. Credit: Zellic._ _Upstream tracking issue: https://github.com/uutils/coreutils/issues/10020 · CVE-2026-35341_

### Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-pmf6-rcx4-v53v. This link is maintained to preserve external references. ### Original Description A vulnerability in uutils coreutils mkfifo allows for the unauthorized modification of permissions on existing files. When mkfifo fails to create a FIFO because a file already exists at the target path, it fails to terminate the operation for that path and continues to execute a follow-up set_permissions call. This results in the existing file's permissions being changed to the default mode (often 644 after umask), potentially exposing sensitive files such as SSH private keys to other users on the system.