CVE-2026-35344

What it actually does

The flaw is an error-handling defect in the uutils coreutils implementation of `dd`. During truncation of an output file, `dd` discards truncation errors by converting the result to `ok()` and not propagating failure to the caller. If truncation fails because the destination is on a full disk, a read-only filesystem, or another filesystem state that prevents truncation, `dd` may still continue or exit as though the operation succeeded. The result can be an output file that retains stale, partial, or garbage data instead of accurately reflecting the intended copy operation. The impact is integrity loss rather than code execution or privilege escalation.

Why it matters to the business

Organizations that use uutils coreutils in backup, restore, imaging, deployment, migration, or data transformation scripts could incorrectly believe a copy operation completed successfully when the output is incomplete or contaminated with old data. This can cause unreliable backups, failed restores, corrupted migration outputs, inaccurate forensic images, or downstream processing of bad data. The vulnerability has low public exploitation likelihood based on the provided EPSS score and is not listed in CISA KEV, but it is operationally important anywhere `dd` is part of automated data-handling workflows.

How an attack unfolds

An attacker with local access, or a non-malicious failure condition such as disk exhaustion, can cause the destination filesystem used by `dd` to reject truncation. For example, the attacker may fill the target filesystem, influence a script to write to a read-only mount, or otherwise create a condition where truncating the destination file fails. Because the vulnerable uutils `dd` suppresses that truncation error, the script may receive a successful exit status or no clear failure signal. The destination file can then contain a mixture of previous contents, incomplete copied data, or stale bytes. If the script uses the resulting file for backups, migrations, images, releases, or verification workflows without independent validation, corrupted data may be accepted as trustworthy.

How to fix it

Upgrade uutils coreutils to a version that correctly propagates truncation failures when a fixed release is available from the project or operating-system package vendor. No fixed version was provided in the input, so track the upstream uutils coreutils advisory and distribution package updates. As interim mitigations, avoid using vulnerable uutils `dd` in integrity-sensitive workflows, substitute GNU coreutils `dd` where appropriate, and update scripts to perform independent validation after copy operations. Recommended safeguards include checking exit status, verifying output size, comparing checksums where feasible, using `fsync` or equivalent durability checks, confirming available disk space before writes, and failing closed if the destination filesystem is read-only or near capacity.

How to confirm the fix worked

Confirm which `dd` implementation is in use by checking the package source and version, for example by reviewing package manager metadata and `dd --version` output. Validate that the installed uutils coreutils build includes a fix once one is available. Reproduce safely in a test environment by attempting a `dd` operation that requires truncating a destination file on a full or read-only filesystem; a fixed build should return a clear error and non-zero failure status rather than silently succeeding. For production workflows, verify that scripts using `dd` independently confirm output size, checksum, and successful write completion, and that monitoring alerts on disk-full and read-only filesystem conditions.

Typical attack path

1. Obtain local access or influence over the environment where uutils `dd` is used in automated scripts.
2. Identify workflows that write important output files using `dd`, such as backup, image creation, restore, migration, or deployment jobs.
3. Create or wait for a filesystem condition that causes truncation to fail, such as a full destination volume or read-only target filesystem.
4. Trigger the `dd` operation so it attempts to overwrite or recreate the destination file.
5. Rely on the vulnerable `dd` behavior to suppress the truncation failure and report apparent success.
6. Cause downstream systems or operators to consume the stale, partial, or corrupted output file.

How to detect it

This issue does not produce a reliable intrusion-specific indicator because exploitation can look like ordinary local use of `dd` combined with filesystem failures. To determine whether it already caused damage or was intentionally triggered, review job logs from backup, restore, migration, image-building, deployment, and forensic workflows that used uutils `dd`. Correlate `dd` executions with system logs showing full disks, quota exhaustion, I/O errors, remounts as read-only, or filesystem permission failures. Examine output artifacts created during those windows for unexpected size mismatches, stale content, checksum mismatches, partial writes, or successful job messages without corresponding validated output. Useful log sources include shell history where available, systemd journal, cron logs, backup application logs, CI/CD job logs, package/container build logs, kernel logs, auditd process execution logs, and filesystem/storage telemetry.

What your security team should do

• Inventory systems and containers using uutils coreutils, especially where `dd` is used in backup, restore, image-building, migration, deployment, or forensic workflows.
• Prioritize remediation for automation that handles critical data, golden images, backups, or restore media, even though the public exploitation probability is currently low.
• Replace vulnerable uutils `dd` with a fixed uutils release or an unaffected implementation where operationally acceptable.
• Add post-copy validation to scripts, including output size checks, checksum comparison, and explicit handling of non-zero exit codes.
• Monitor for disk-full, quota-exceeded, and read-only filesystem events on systems that run data-copy automation.
• Test backup and restore integrity rather than relying solely on successful job completion messages.
• Track upstream and distribution advisories for an exact fixed uutils coreutils version, since none was provided in the vulnerability metadata.