Hello everyone,
While playing with sbase and musl, I encountered a strange bug: tar
fails to extract bzip2 compressed archives when bzip2 is compiled
against musl (I only tested static linking). Note that bzip2 uncompresses
the files correctly. The error only occurs when the data flows through
a pipe:
The file has been created using GNU/tar, dynamically compiled against glibc.
As a reference, here is a test with the static bzip2 and GNU/tar:
If using the bzip2 binary provided with my distro (v1.0.6), everything
works as expected:
$ /usr/bin/bzip2 -d < pm.tbz | musl/tar -t
pm/
pm/IDEAS
pm/LICENSE
pm/README
pm/arg.h
pm/makefile
pm/pack.5
pm/pm.1
pm/pm.c
pm/config.mk
As I said earlier, The error occurs only with a pipe in-between, so
uncompressing the file completely before extracting it works flawlessly:
$ musl/bzip2 -d < pm.tbz > pm.tar
$ musl/tar -tf pm.tar
pm/
pm/IDEAS
pm/LICENSE
pm/README
pm/arg.h
pm/makefile
pm/pack.5
pm/pm.1
pm/pm.c
pm/config.mk
I added some debug messages to `chktar()` in order to identify what is
going wrong (see patch attached), and the error changes (apparently)
randomly.
Sometime, extracting simply stop without an error:
$ musl/bzip2 -d < pm.tbz | musl/tar -t
pm/
pm/IDEAS
pm/LICENSE
pm/README
Sometimes the magic string is wrong (header is read within a previous
entry):
$ musl/bzip2 -d < pm.tbz | musl/tar -t
pm/
pm/IDEAS
pm/LICENSE
pm/README
pm/arg.h
pm/makefile
pm/pack.5
pm/pm.1
pm/pm.c
chktar: invalid magic "ootfs, datadir, *argv);
if (action == ACTION_UPDATE)
r += update(rootfs, datadir, *argv);
if (action == ACTION_DELETE)
r += delete(rootfs, datadir, *argv);
argv++;
}
break;
case ACTION_INSPECT:
if (inspect(datadir, n) != 0)
retu"
musl/tar: malformed tar archive
And sometimes the magic string is ok, but the checksum fails:
$ musl/bzip2 -d < pm.tbz | musl/tar -t
pm/
pm/IDEAS
pm/LICENSE
pm/README
pm/arg.h
pm/makefile
pm/pack.5
pm/pm.1
chktar: bad checksum
musl/tar: malformed tar archive
At this point, I'm not sure where to look at, or even if the bug
really lies in tar and not in bzip2.
I checked the size (both octal and converted) and the value is good. So
I'm not sure why the headers are not well read.
In the case of the archive above, the error occurs on the last entry,
but depending on the archives, it can occur on the second entry or in
the middle, there's no rule.
I hope my example are clear to define what the issue is. Would anyone
have an idea?
--
willy
Received on Thu Feb 02 2017 - 19:20:34 CET