Skip to content

mkfifo: permissions of an existing file are changed after FIFO creation fails

High
sylvestre published GHSA-pmf6-rcx4-v53v May 30, 2026

Package

cargo uu_mkfifo (Rust)

Affected versions

< 0.6.0

Patched versions

0.6.0

Description

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: #10020 · CVE-2026-35341

Severity

High

CVE ID

CVE-2026-35341

Weaknesses

Improper Preservation of Permissions

The product does not preserve permissions or incorrectly preserves permissions when copying, restoring, or sharing objects, which can cause them to have less restrictive permissions than intended. Learn more on MITRE.

Incorrect Permission Assignment for Critical Resource

The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors. Learn more on MITRE.