Bug#466771: busybox cpio: double free or corruption during cpio extraction of hardlinks
Package: busybox
Version: 1:1.1.3-5
Severity: important
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
busybox cpio seems to corrupt its memory (maybe with a double free?)
when extracting a hardlink.
Here's a transcript of a simple case to trigger the failure:
0 dkg@ape:/tmp$ mkdir tt
0 dkg@ape:/tmp$ touch tt/x
0 dkg@ape:/tmp$ ln tt/x tt/y
0 dkg@ape:/tmp$ mkdir xx
0 dkg@ape:/tmp$ find tt | cpio -H newc --create | (cd xx && busybox cpio -i)
1 block
1 blocks
cpio: TRAILER!!! not created: cannot resolve hardlink
cpio: (null) not created: cannot resolve hardlink
*** glibc detected *** busybox: double free or corruption (fasttop): 0x08178048 ***
======= Backtrace: =========
/lib/i686/cmov/libc.so.6[0xb7dd8915]
/lib/i686/cmov/libc.so.6(cfree+0x90)[0xb7ddc380]
busybox[0x805378b]
======= Memory map: ========
08048000-080ac000 r-xp 00000000 fd:0a 65545 /bin/busybox
080ac000-080ae000 rwxp 00064000 fd:0a 65545 /bin/busybox
080ae000-08199000 rwxp 080ae000 00:00 0 [heap]
b7c00000-b7c21000 rwxp b7c00000 00:00 0
b7c21000-b7d00000 ---p b7c21000 00:00 0
b7d6c000-b7d6d000 rwxp b7d6c000 00:00 0
b7d6d000-b7eb4000 r-xp 00000000 fd:0a 114782 /lib/i686/cmov/libc-2.7.so
b7eb4000-b7eb5000 r-xp 00147000 fd:0a 114782 /lib/i686/cmov/libc-2.7.so
b7eb5000-b7eb7000 rwxp 00148000 fd:0a 114782 /lib/i686/cmov/libc-2.7.so
b7eb7000-b7eba000 rwxp b7eb7000 00:00 0
b7eba000-b7edd000 r-xp 00000000 fd:0a 114787 /lib/i686/cmov/libm-2.7.so
b7edd000-b7edf000 rwxp 00023000 fd:0a 114787 /lib/i686/cmov/libm-2.7.so
b7edf000-b7ee8000 r-xp 00000000 fd:0a 114784 /lib/i686/cmov/libcrypt-2.7.so
b7ee8000-b7eea000 rwxp 00008000 fd:0a 114784 /lib/i686/cmov/libcrypt-2.7.so
b7eea000-b7f12000 rwxp b7eea000 00:00 0
b7f1a000-b7f26000 r-xp 00000000 fd:0a 114764 /lib/libgcc_s.so.1
b7f26000-b7f27000 rwxp 0000b000 fd:0a 114764 /lib/libgcc_s.so.1
b7f27000-b7f29000 rwxp b7f27000 00:00 0
b7f29000-b7f45000 r-xp 00000000 fd:0a 114725 /lib/ld-2.7.so
b7f45000-b7f47000 rwxp 0001b000 fd:0a 114725 /lib/ld-2.7.so
bffb3000-bffc8000 rw-p bffeb000 00:00 0 [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
134 dkg@ape:/tmp$
The standard cpio doesn't seem to have this problem:
0 dkg@ape:/tmp$ rm -rf xx
0 dkg@ape:/tmp$ mkdir xx
0 dkg@ape:/tmp$ find tt | cpio -H newc --create | (cd xx && cpio -i)
1 block
1 block
0 dkg@ape:/tmp$ ls -lR xx
xx:
total 0
drwxr-xr-x 2 wt215 wt215 80 2008-02-20 15:26 tt
xx/tt:
total 0
- -rw-r--r-- 2 wt215 wt215 0 2008-02-20 15:26 x
- -rw-r--r-- 2 wt215 wt215 0 2008-02-20 15:26 y
0 dkg@ape:/tmp$
This seems to happen with -t (list) the same as -i (extract), so i
expect it's a problem with parsing, not file creation.
fwiw, it doesn't seem to be a problem with busybox 1.9.1, as built
with waldi's debian packaging at:
svn://svn.debian.org/d-i/people/waldi/packages/busybox/debian
With version 1.9.1, it still doesn't unpack the hardlinks, but it
doesn't double-free, at least:
0 dkg@ape:/tmp$ find tt | cpio -H newc --create | (cd xx && ~/src/busybox/busybox-1.9.1/debian/busybox/bin/busybox cpio -i)
1 block
1 blocks
cpio: tt/x not created: cannot resolve hardlink
cpio: tt/y not created: cannot resolve hardlink
0 dkg@ape:/tmp$ find xx
xx
xx/tt
0 dkg@ape:/tmp$
Thanks for maintaining busybox in debian!
--dkg
- -- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable'), (101, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages busybox depends on:
ii libc6 2.7-6 GNU C Library: Shared libraries
busybox recommends no packages.
- -- no debconf information
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iQIVAwUBR7yP7szS7ZTSFznpAQKKqw/+MzMP1qA+Ips+xfvshkybvzi436MaDdCM
byP3jbAK0JHvH4Yp4d80ZZD09S21LhlEIfMvPfrZmjmnrWw89QiTB61mNuJHq8xB
JmaHZku/5uXsM5xhk8aTv9xLWrC0R/6iUu3r+9sUwWKwcg3SwCeFeLitV08TYlgM
pO7Fr1uVpBd13A5JZiLvgoSEC6BIjR1ct3yzDbi7B1oOMwPQBF+BkSxUmOsEsQU1
C4VhS+kvQ6YLFqc07PlXbaGH78waWbo2z3Oacsn7gEVbbNKjTIorwcvlAu9fYPHy
MbufuWlVQyddJIwHj9b3Qtq28xHDDyZYn5pnSJ2xjl7Q4OZcbUCSUWnRjUp2SJGH
ZQJZpEBE7utYBDWYFsAuq8vGVziOk47/TZSgWqWvCxHt/ZqBrkGsAlrItL9Ies+C
VmQGU7yqbouRHovrc2vwDsB1j8MjUt2DfrHNt+7ElSBcGwKnhdkeK7gEfLFRuLUp
jvOAzFISdGurDEgkNkmZRKinS+/98xy4RvxKXkp4JpVXiF+SNMAwzsgivuYdYQ+g
/UKSLVHEgly4KogPYXwEAT7/GD6jkgZgmVnJycAdhXSMGyGWUF6AkAFfuqPHk8u3
d5tB72G8jhkVu9IPx/g2fhczu1BNKXllOQBpzGnYkMbUPSKj8xgvn761zZeYKaZM
9bihbCO4/mQ=
=vs9z
-----END PGP SIGNATURE-----
Reply to: