Sat Apr 25 11:25:26 BST 2026

Source: rust-coreutils
X-Debbugs-CC: team at security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for rust-coreutils.

These are all fixed in 0.8.0:

CVE-2026-35338[0]:
| A vulnerability in the chmod utility of uutils coreutils allows
| users to bypass the --preserve-root safety mechanism. The
| implementation only validates if the target path is literally / and
| does not canonicalize the path. An attacker or accidental user can
| use path variants such as /../ or symbolic links to execute
| destructive recursive operations (e.g., chmod -R 000) on the entire
| root filesystem, leading to system-wide permission loss and
| potential complete system breakdown.

CVE-2026-35341[1]:
| 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.

CVE-2026-35343[2]:
| The cut utility in uutils coreutils incorrectly handles the -s
| (only-delimited) option when a newline character is specified as the
| delimiter. The implementation fails to verify the only_delimited
| flag in the cut_fields_newline_char_delim function, causing the
| utility to print non-delimited lines that should have been
| suppressed. This can lead to unexpected data being passed to
| downstream scripts that rely on strict output filtering.

CVE-2026-35344[3]:
| The dd utility in uutils coreutils suppresses errors during file
| truncation operations by unconditionally calling Result::ok() on
| truncation attempts. While intended to mimic GNU behavior for
| special files like /dev/null, the uutils implementation also hides
| failures on regular files and directories caused by full disks or
| read-only file systems. This can lead to silent data corruption in
| backup or migration scripts, as the utility may report a successful
| operation even when the destination file contains old or garbage
| data.

CVE-2026-35345[4]:
| A vulnerability in the tail utility of uutils coreutils allows for
| the exfiltration of sensitive file contents when using the
| --follow=name option. Unlike GNU tail, the uutils implementation
| continues to monitor a path after it has been replaced by a symbolic
| link, subsequently outputting the contents of the link's target. In
| environments where a privileged user (e.g., root) monitors a log
| directory, a local attacker with write access to that directory can
| replace a log file with a symlink to a sensitive system file (such
| as /etc/shadow), causing tail to disclose the contents of the
| sensitive file.

CVE-2026-35348[5]:
| The sort utility in uutils coreutils is vulnerable to a process
| panic when using the --files0-from option with inputs containing
| non-UTF-8 filenames. The implementation enforces UTF-8 encoding and
| utilizes expect(), causing an immediate crash when encountering
| valid but non-UTF-8 paths. This diverges from GNU sort, which treats
| filenames as raw bytes. A local attacker can exploit this to crash
| the utility and disrupt automated pipelines.

CVE-2026-35350[6]:
| The cp utility in uutils coreutils fails to properly handle setuid
| and setgid bits when ownership preservation fails. When copying with
| the -p (preserve) flag, the utility applies the source mode bits
| even if the chown operation is unsuccessful. This can result in a
| user-owned copy retaining original privileged bits, creating
| unexpected privileged executables that violate local security
| policies. This differs from GNU cp, which clears these bits when
| ownership cannot be preserved.

CVE-2026-35351[7]:
| The mv utility in uutils coreutils fails to preserve file ownership
| during moves across different filesystem boundaries. The utility
| falls back to a copy-and-delete routine that creates the destination
| file using the caller's UID/GID rather than the source's metadata.
| This flaw breaks backups and migrations, causing files moved by a
| privileged user (e.g., root) to become root-owned unexpectedly,
| which can lead to information disclosure or restricted access for
| the intended owners.

CVE-2026-35352[8]:
| A Time-of-Check to Time-of-Use (TOCTOU) race condition exists in the
| mkfifo utility of uutils coreutils. The utility creates a FIFO and
| then performs a path-based chmod to set permissions. A local
| attacker with write access to the parent directory can swap the
| newly created FIFO for a symbolic link between these two operations.
| This redirects the chmod call to an arbitrary file, potentially
| enabling privilege escalation if the utility is run with elevated
| privileges.

CVE-2026-35354[9]:
| A Time-of-Check to Time-of-Use (TOCTOU) vulnerability exists in the
| mv utility of uutils coreutils during cross-device moves. The
| extended attribute (xattr) preservation logic uses multiple path-
| based system calls that perform fresh path-to-inode lookups for each
| operation. A local attacker with write access to the directory can
| exploit this race to swap files between calls, causing the
| destination file to receive an inconsistent mix of security xattrs,
| such as SELinux labels or file capabilities.

CVE-2026-35357[10]:
| The cp utility in uutils coreutils is vulnerable to an information
| disclosure race condition. Destination files are initially created
| with umask-derived permissions (e.g., 0644) before being restricted
| to their final mode (e.g., 0600) later in the process. A local
| attacker can race to open the file during this window; once
| obtained, the file descriptor remains valid and readable even after
| the permissions are tightened, exposing sensitive or private file
| contents.

CVE-2026-35359[11]:
| A Time-of-Check to Time-of-Use (TOCTOU) vulnerability in the cp
| utility of uutils coreutils allows an attacker to bypass no-
| dereference intent. The utility checks if a source path is a
| symbolic link using path-based metadata but subsequently opens it
| without the O_NOFOLLOW flag. An attacker with concurrent write
| access can swap a regular file for a symbolic link during this
| window, causing a privileged cp process to copy the contents of
| arbitrary sensitive files into a destination controlled by the
| attacker.

CVE-2026-35360[12]:
| The touch utility in uutils coreutils is vulnerable to a Time-of-
| Check to Time-of-Use (TOCTOU) race condition during file creation.
| When the utility identifies a missing path, it later attempts
| creation using File::create(), which internally uses O_TRUNC. An
| attacker can exploit this window to create a file or swap a symlink
| at the target path, causing touch to truncate an existing file and
| leading to permanent data loss.

CVE-2026-35363[13]:
| A vulnerability in the rm utility of uutils coreutils allows the
| bypass of safeguard mechanisms intended to protect the current
| directory. While the utility correctly refuses to delete . or .., it
| fails to recognize equivalent paths with trailing slashes, such as
| ./ or .///. An accidental or malicious execution of rm -rf ./
| results in the silent recursive deletion of all contents within the
| current directory. The command further obscures the data loss by
| reporting a misleading 'Invalid input' error, which may cause users
| to miss the critical window for data recovery.

CVE-2026-35364[14]:
| A Time-of-Check to Time-of-Use (TOCTOU) race condition exists in the
| mv utility of uutils coreutils during cross-device operations. The
| utility removes the destination path before recreating it through a
| copy operation. A local attacker with write access to the
| destination directory can exploit this window to replace the
| destination with a symbolic link. The subsequent privileged move
| operation will follow the symlink, allowing the attacker to redirect
| the write and overwrite an arbitrary target file with contents from
| the source.

CVE-2026-35365[15]:
| The mv utility in uutils coreutils improperly handles directory
| trees containing symbolic links during moves across filesystem
| boundaries. Instead of preserving symlinks, the implementation
| expands them, copying the linked targets as real files or
| directories at the destination. This can lead to resource exhaustion
| (disk space or time) if symlinks point to large external
| directories, unexpected duplication of sensitive data into
| unintended locations, or infinite recursion and repeated copying in
| the presence of symlink loops.

CVE-2026-35367[16]:
| The nohup utility in uutils coreutils creates its default output
| file, nohup.out, without specifying explicit restricted permissions.
| This causes the file to inherit umask-based permissions, typically
| resulting in a world-readable file (0644). In multi-user
| environments, this allows any user on the system to read the
| captured stdout/stderr output of a command, potentially exposing
| sensitive information. This behavior diverges from GNU coreutils,
| which creates nohup.out with owner-only (0600) permissions.

CVE-2026-35368[17]:
| A vulnerability exists in the chroot utility of uutils coreutils
| when using the --userspec option. The utility resolves the user
| specification via getpwnam() after entering the chroot but before
| dropping root privileges. On glibc-based systems, this can trigger
| the Name Service Switch (NSS) to load shared libraries (e.g.,
| libnss_*.so.2) from the new root directory. If the NEWROOT is
| writable by an attacker, they can inject a malicious NSS module to
| execute arbitrary code as root, facilitating a full container escape
| or privilege escalation.

CVE-2026-35370[18]:
| The id utility in uutils coreutils miscalculates the groups= section
| of its output. The implementation uses a user's real GID instead of
| their effective GID to compute the group list, leading to
| potentially divergent output compared to GNU coreutils. Because many
| scripts and automated processes rely on the output of id to make
| security-critical access-control or permission decisions, this
| discrepancy can lead to unauthorized access or security
| misconfigurations.

CVE-2026-35371[19]:
| The id utility in uutils coreutils exhibits incorrect behavior in
| its "pretty print" output when the real UID and effective UID
| differ. The implementation incorrectly uses the effective GID
| instead of the effective UID when performing a name lookup for the
| effective user. This results in misleading diagnostic output that
| can cause automated scripts or system administrators to make
| incorrect decisions regarding file permissions or access control.

CVE-2026-35372[20]:
| A logic error in the ln utility of uutils coreutils allows the
| utility to dereference a symbolic link target even when the --no-
| dereference (or -n) flag is explicitly provided. The implementation
| previously only honored the "no-dereference" intent if the --force
| (overwrite) mode was also enabled. This flaw causes ln to follow a
| symbolic link that points to a directory and create new links inside
| that target directory instead of treating the symbolic link itself
| as the destination. In environments where a privileged user or
| system script uses ln -n to update a symlink, a local attacker could
| manipulate existing symbolic links to redirect file creation into
| sensitive directories, potentially leading to unauthorized file
| creation or system misconfiguration.

CVE-2026-35373[21]:
| A logic error in the ln utility of uutils coreutils causes the
| program to reject source paths containing non-UTF-8 filename bytes
| when using target-directory forms (e.g., ln SOURCE... DIRECTORY).
| While GNU ln treats filenames as raw bytes and creates the links
| correctly, the uutils implementation enforces UTF-8 encoding,
| resulting in a failure to stat the file and a non-zero exit code. In
| environments where automated scripts or system tasks process valid
| but non-UTF-8 filenames common on Unix filesystems, this divergence
| causes the utility to fail, leading to a local denial of service for
| those specific operations.

CVE-2026-35374[22]:
| A Time-of-Check to Time-of-Use (TOCTOU) vulnerability exists in the
| split utility of uutils coreutils. The program attempts to prevent
| data loss by checking for identity between input and output files
| using their file paths before initiating the split operation.
| However, the utility subsequently opens the output file with
| truncation after this path-based validation is complete. A local
| attacker with write access to the directory can exploit this race
| window by manipulating mutable path components (e.g., swapping a
| path with a symbolic link). This can cause split to truncate and
| write to an unintended target file, potentially including the input
| file itself or other sensitive files accessible to the process,
| leading to permanent data loss.

CVE-2026-35375[23]:
| A logic error in the split utility of uutils coreutils causes the
| corruption of output filenames when provided with non-UTF-8 prefix
| or suffix inputs. The implementation utilizes to_string_lossy() when
| constructing chunk filenames, which automatically rewrites invalid
| byte sequences into the UTF-8 replacement character (U+FFFD). This
| behavior diverges from GNU split, which preserves raw pathname bytes
| intact. In environments utilizing non-UTF-8 encodings, this
| vulnerability leads to the creation of files with incorrect names,
| potentially causing filename collisions, broken automation, or the
| misdirection of output data.

CVE-2026-35376[24]:
| A Time-of-Check to Time-of-Use (TOCTOU) vulnerability exists in the
| chcon utility of uutils coreutils during recursive operations. The
| implementation resolves recursive targets using a fresh path lookup
| (via fts_accpath) rather than binding the traversal and label
| application to the specific directory state encountered during
| traversal. Because these operations are not anchored to file
| descriptors, a local attacker with write access to a directory tree
| can exploit timing-sensitive rename or symbolic link races to
| redirect a privileged recursive relabeling operation to unintended
| files or directories. This vulnerability breaks the hardening
| expectations for SELinux administration workflows and can lead to
| the unauthorized modification of security labels on sensitive system
| objects.

CVE-2026-35377[25]:
| A logic error in the env utility of uutils coreutils causes a
| failure to correctly parse command-line arguments when utilizing the
| -S (split-string) option. In GNU env, backslashes within single
| quotes are treated literally (with the exceptions of \\ and \').
| However, the uutils implementation incorrectly attempts to validate
| these sequences, resulting in an "invalid sequence" error and an
| immediate process termination with an exit status of 125 when
| encountering valid but unrecognized sequences like \a or \x. This
| divergence from GNU behavior breaks compatibility for automated
| scripts and administrative workflows that rely on standard split-
| string semantics, leading to a local denial of service for those
| operations.

CVE-2026-35378[26]:
| A logic error in the expr utility of uutils coreutils causes the
| program to evaluate parenthesized subexpressions during the parsing
| phase rather than at the execution phase. This implementation flaw
| prevents the utility from performing proper short-circuiting for
| logical OR (|) and AND (&) operations. As a result, arithmetic
| errors (such as division by zero) occurring within "dead" branches,
| branches that should be ignored due to short-circuiting, are raised
| as fatal errors. This divergence from GNU expr behavior can cause
| guarded expressions within shell scripts to fail with hard errors
| instead of returning expected boolean results, leading to premature
| script termination and breaking GNU-compatible shell control flow.

CVE-2026-35379[27]:
| A logic error in the tr utility of uutils coreutils causes the
| program to incorrectly define the [:graph:] and [:print:] character
| classes. The implementation mistakenly includes the ASCII space
| character (0x20) in the [:graph:] class and excludes it from the
| [:print:] class, effectively reversing the standard behavior
| established by POSIX and GNU coreutils. This vulnerability leads to
| unintended data modification or loss when the utility is used in
| automated scripts or data-cleaning pipelines that rely on standard
| character class semantics. For example, a command executed to delete
| all graphical characters while intending to preserve whitespace will
| incorrectly delete all ASCII spaces, potentially resulting in data
| corruption or logic failures in downstream processing.

CVE-2026-35380[28]:
| A logic error in the cut utility of uutils coreutils causes the
| program to incorrectly interpret the literal two-byte string '' (two
| single quotes) as an empty delimiter. The implementation mistakenly
| maps this string to the NUL character for both the -d (delimiter)
| and --output-delimiter options. This vulnerability can lead to
| silent data corruption or logic errors in automated scripts and data
| pipelines that process strings containing these characters, as the
| utility may unintentionally split or join data on NUL bytes rather
| than the intended literal characters.

CVE-2026-35381[29]:
| A logic error in the cut utility of uutils coreutils causes the
| utility to ignore the -s (only-delimited) flag when using the -z
| (null-terminated) and -d '' (empty delimiter) options together. The
| implementation incorrectly routes this specific combination through
| a specialized newline-delimiter code path that fails to check the
| record suppression status. Consequently, uutils cut emits the entire
| record plus a NUL byte instead of suppressing it. This divergence
| from GNU coreutils behavior creates a data integrity risk for
| automated pipelines that rely on cut -s to filter out undelimited
| data.

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2026-35338
    https://www.cve.org/CVERecord?id=CVE-2026-35338
[1] https://security-tracker.debian.org/tracker/CVE-2026-35341
    https://www.cve.org/CVERecord?id=CVE-2026-35341
[2] https://security-tracker.debian.org/tracker/CVE-2026-35343
    https://www.cve.org/CVERecord?id=CVE-2026-35343
[3] https://security-tracker.debian.org/tracker/CVE-2026-35344
    https://www.cve.org/CVERecord?id=CVE-2026-35344
[4] https://security-tracker.debian.org/tracker/CVE-2026-35345
    https://www.cve.org/CVERecord?id=CVE-2026-35345
[5] https://security-tracker.debian.org/tracker/CVE-2026-35348
    https://www.cve.org/CVERecord?id=CVE-2026-35348
[6] https://security-tracker.debian.org/tracker/CVE-2026-35350
    https://www.cve.org/CVERecord?id=CVE-2026-35350
[7] https://security-tracker.debian.org/tracker/CVE-2026-35351
    https://www.cve.org/CVERecord?id=CVE-2026-35351
[8] https://security-tracker.debian.org/tracker/CVE-2026-35352
    https://www.cve.org/CVERecord?id=CVE-2026-35352
[9] https://security-tracker.debian.org/tracker/CVE-2026-35354
    https://www.cve.org/CVERecord?id=CVE-2026-35354
[10] https://security-tracker.debian.org/tracker/CVE-2026-35357
    https://www.cve.org/CVERecord?id=CVE-2026-35357
[11] https://security-tracker.debian.org/tracker/CVE-2026-35359
    https://www.cve.org/CVERecord?id=CVE-2026-35359
[12] https://security-tracker.debian.org/tracker/CVE-2026-35360
    https://www.cve.org/CVERecord?id=CVE-2026-35360
[13] https://security-tracker.debian.org/tracker/CVE-2026-35363
    https://www.cve.org/CVERecord?id=CVE-2026-35363
[14] https://security-tracker.debian.org/tracker/CVE-2026-35364
    https://www.cve.org/CVERecord?id=CVE-2026-35364
[15] https://security-tracker.debian.org/tracker/CVE-2026-35365
    https://www.cve.org/CVERecord?id=CVE-2026-35365
[16] https://security-tracker.debian.org/tracker/CVE-2026-35367
    https://www.cve.org/CVERecord?id=CVE-2026-35367
[17] https://security-tracker.debian.org/tracker/CVE-2026-35368
    https://www.cve.org/CVERecord?id=CVE-2026-35368
[18] https://security-tracker.debian.org/tracker/CVE-2026-35370
    https://www.cve.org/CVERecord?id=CVE-2026-35370
[19] https://security-tracker.debian.org/tracker/CVE-2026-35371
    https://www.cve.org/CVERecord?id=CVE-2026-35371
[20] https://security-tracker.debian.org/tracker/CVE-2026-35372
    https://www.cve.org/CVERecord?id=CVE-2026-35372
[21] https://security-tracker.debian.org/tracker/CVE-2026-35373
    https://www.cve.org/CVERecord?id=CVE-2026-35373
[22] https://security-tracker.debian.org/tracker/CVE-2026-35374
    https://www.cve.org/CVERecord?id=CVE-2026-35374
[23] https://security-tracker.debian.org/tracker/CVE-2026-35375
    https://www.cve.org/CVERecord?id=CVE-2026-35375
[24] https://security-tracker.debian.org/tracker/CVE-2026-35376
    https://www.cve.org/CVERecord?id=CVE-2026-35376
[25] https://security-tracker.debian.org/tracker/CVE-2026-35377
    https://www.cve.org/CVERecord?id=CVE-2026-35377
[26] https://security-tracker.debian.org/tracker/CVE-2026-35378
    https://www.cve.org/CVERecord?id=CVE-2026-35378
[27] https://security-tracker.debian.org/tracker/CVE-2026-35379
    https://www.cve.org/CVERecord?id=CVE-2026-35379
[28] https://security-tracker.debian.org/tracker/CVE-2026-35380
    https://www.cve.org/CVERecord?id=CVE-2026-35380
[29] https://security-tracker.debian.org/tracker/CVE-2026-35381
    https://www.cve.org/CVERecord?id=CVE-2026-35381

Please adjust the affected versions in the BTS as needed.