Public bug reported:
GNU tar with the USN-8477-1 security fix for CVE-2026-5704 can no longer
extract files which previously extracted successfully. The problem files
are (by the standard) invalid, but still extracted successfully prior to
this fix. The problem files can also be extracted by any other tar
implementation.
My team wrote a ustar archive generator years ago. It mistakenly
generates archives where all hardlinks have a 'size' value equal to the
size of their target. If the implementation was correct, it would
generate all hardlinks with a size of 0. Obviously the implementation is
wrong, and it's been fixed now, but we have years of tarballs with this
problem which would be very difficult to regenerate and redistribute.
Previous versions of GNU Tar in Ubuntu could test and extract the
invalid tarballs successfully. Current versions of libarchive-tools'
bsdtar can also extract the invalid tarballs successfully.
I've attached a Python script which generates a tiny tarball which reproduces
the problem. It generates a pax archive (ustar wasn't working in my version of
Python and the format doesn't seem to matter) with a hardlink with a size value
of 1. Older versions of GNU Tar in Ubuntu test and extract this file without
issue:
$ tar -tvf bad.tar
-rw-r--r-- 0/0 0 1969-12-31 17:00 ./file.txt
hrw-r--r-- 0/0 0 1969-12-31 17:00 ./badhardlink link to file.txt
hrw-r--r-- 0/0 0 1969-12-31 17:00 ./goodhardlink link to
file.txt
$ apt policy tar
tar:
Installed: 1.34+dfsg-1build3
While new versions act like goodhardlink doesn't exist:
$ tar -tvf bad.tar
-rw-r--r-- 0/0 0 1969-12-31 17:00 ./file.txt
hrw-r--r-- 0/0 1 1969-12-31 17:00 ./badhardlink link to file.txt
$ apt policy tar
tar:
Installed: 1.34+dfsg-1ubuntu0.1.22.04.4
As a more general statement about the security fix, it seems that most
implementations of tar (including Golang's archive/tar, Python's tarfile, and
libarchive) fix the problem the opposite way of Ubuntu's fix for GNU Tar. Most
implementations ignore the size value on special file types and assume it is
zero regardless of the archive's header. This allows locating the injected
files listed in the original bug report[1] without breaking archive parsing
(this example taken on a Mac with gtar installed from Homebrew and tar being
the built-in libarchive version:
% gtar -tvf desync_symlink.tar
lrw-r--r-- root/root 1024 2026-03-18 08:45 carrier_entry -> /dev/null
-rw-r--r-- root/root 10 2026-03-18 08:45 marker.txt
% tar -tvf desync_symlink.tar
lrw-r--r-- 0 root root 0 Mar 18 08:45 carrier_entry -> /dev/null
-rwxr-xr-x 0 root root 50 Mar 18 08:45 injected.txt
-rw-r--r-- 0 root root 10 Mar 18 08:45 marker.txt
[1] https://lists.gnu.org/r/bug-tar/2026-03/msg00007.html
** Affects: tar (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: "badtargenerator.py"
https://bugs.launchpad.net/bugs/2160650/+attachment/5981860/+files/badtargenerator.py
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2160650
Title:
tar after USN-8477-1 cannot extract previously valid files
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tar/+bug/2160650/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
