Bug#577706: newenvp buffer overrun in execve()
fixed 577706 2.10 thanks This bug was resolved in 2.10 release. Thank you! 2010/4/13 Tomi Belan tomi.be...@gmail.com Package: fakechroot Version: 2.9 Programs under fakechroot can crash in execve() if all of the FAKECHROOT, FAKECHROOT_BASE, FAKECHROOT_VERSION, FAKECHROOT_EXCLUDE_PATH, LD_LIBRARY_PATH, LD_PRELOAD variables are set. An example of a program using execve() is gcc. This means that unless FAKECHROOT_EXCLUDE_PATH (or another one of the variables above) is unset, using gcc in fakechroot is impossible. How to test: $ export FAKECHROOT_EXCLUDE_PATH= $ echo | fakechroot chroot / gcc -x c - What I expected to see (because / isn't writable): /usr/bin/ld: cannot open output file a.out: Permission denied collect2: ld returned 1 exit status What I saw instead: *** glibc detected *** gcc: corrupted double-linked list: 0x08906190 *** === Backtrace: = /lib/libc.so.6(+0x6bb61)[0xb77b7b61] /lib/libc.so.6(+0x6d411)[0xb77b9411] /lib/libc.so.6(cfree+0x6d)[0xb77bc4ad] gcc[0x805e08e] gcc[0x8054b3b] /lib/libc.so.6(__libc_start_main+0xe6)[0xb7762b86] gcc[0x8049661] === Memory map: 08048000-08079000 r-xp 08:03 54690299 /usr/bin/gcc 08079000-0807b000 rw-p 0003 08:03 54690299 /usr/bin/gcc 088ff000-0892 rw-p 00:00 0 [heap] b740-b7421000 rw-p 00:00 0 b7421000-b750 ---p 00:00 0 b7551000-b756d000 r-xp 08:03 4486578/usr/lib/libgcc_s.so.1 b756d000-b756e000 rw-p 0001c000 08:03 4486578/usr/lib/libgcc_s.so.1 b756e000-b773b000 r--p 08:03 54577410 /usr/lib/locale/locale-archive b773b000-b7745000 r-xp 08:03 4303501/lib/ libnss_files-2.11.1.so b7745000-b7746000 r--p 9000 08:03 4303501/lib/ libnss_files-2.11.1.so b7746000-b7747000 rw-p a000 08:03 4303501/lib/ libnss_files-2.11.1.so b7747000-b7748000 rw-p 00:00 0 b7748000-b774a000 r-xp 08:03 4328458/lib/libdl-2.11.1.so b774a000-b774b000 r--p 1000 08:03 4328458/lib/libdl-2.11.1.so b774b000-b774c000 rw-p 2000 08:03 4328458/lib/libdl-2.11.1.so b774c000-b788d000 r-xp 08:03 4303498/lib/libc-2.11.1.so b788d000-b788f000 r--p 0014 08:03 4303498/lib/libc-2.11.1.so b788f000-b789 rw-p 00142000 08:03 4303498/lib/libc-2.11.1.so b789-b7893000 rw-p 00:00 0 b7893000-b789e000 r-xp 08:03 17009921 /usr/lib/libfakeroot/fakechroot/libfakechroot.so b789e000-b789f000 rw-p a000 08:03 17009921 /usr/lib/libfakeroot/fakechroot/libfakechroot.so b789f000-b78a rw-p 00:00 0 b78a-b78a1000 r-xp 00:00 0 [vdso] b78a1000-b78bd000 r-xp 08:03 4330037/lib/ld-2.11.1.so b78bd000-b78be000 r--p 0001b000 08:03 4330037/lib/ld-2.11.1.so b78be000-b78bf000 rw-p 0001c000 08:03 4330037/lib/ld-2.11.1.so bffc9000-bffde000 rw-p 00:00 0 [stack] Aborted gdb /bin/true crashes similarly. The bug is caused by the newenvp array overflowing in execve() and can be fixed by replacing i with (i+1) in execve()'s realloc() call. However, I found out that the bug is already fixed in SVN, which makes me concerned that the fix wasn't released yet. If it's because the trunk is unstable at the moment, please consider doing a separate bugfix release. Building software is one of the main uses of fakechroot, and being unable to use gcc (together with FAKECHROOT_EXCLUDE_PATH) seriously reduces its functionality. I am using fakechroot-2.9 compiled from source on ArchLinux. -- .''`.Piotr Roszatycki : :' :mailto:piotr.roszaty...@gmail.com `. `' mailto:dex...@debian.org `-
Bug#577706: newenvp buffer overrun in execve()
Package: fakechroot Version: 2.9 Programs under fakechroot can crash in execve() if all of the FAKECHROOT, FAKECHROOT_BASE, FAKECHROOT_VERSION, FAKECHROOT_EXCLUDE_PATH, LD_LIBRARY_PATH, LD_PRELOAD variables are set. An example of a program using execve() is gcc. This means that unless FAKECHROOT_EXCLUDE_PATH (or another one of the variables above) is unset, using gcc in fakechroot is impossible. How to test: $ export FAKECHROOT_EXCLUDE_PATH= $ echo | fakechroot chroot / gcc -x c - What I expected to see (because / isn't writable): /usr/bin/ld: cannot open output file a.out: Permission denied collect2: ld returned 1 exit status What I saw instead: *** glibc detected *** gcc: corrupted double-linked list: 0x08906190 *** === Backtrace: = /lib/libc.so.6(+0x6bb61)[0xb77b7b61] /lib/libc.so.6(+0x6d411)[0xb77b9411] /lib/libc.so.6(cfree+0x6d)[0xb77bc4ad] gcc[0x805e08e] gcc[0x8054b3b] /lib/libc.so.6(__libc_start_main+0xe6)[0xb7762b86] gcc[0x8049661] === Memory map: 08048000-08079000 r-xp 08:03 54690299 /usr/bin/gcc 08079000-0807b000 rw-p 0003 08:03 54690299 /usr/bin/gcc 088ff000-0892 rw-p 00:00 0 [heap] b740-b7421000 rw-p 00:00 0 b7421000-b750 ---p 00:00 0 b7551000-b756d000 r-xp 08:03 4486578/usr/lib/libgcc_s.so.1 b756d000-b756e000 rw-p 0001c000 08:03 4486578/usr/lib/libgcc_s.so.1 b756e000-b773b000 r--p 08:03 54577410 /usr/lib/locale/locale-archive b773b000-b7745000 r-xp 08:03 4303501/lib/libnss_files-2.11.1.so b7745000-b7746000 r--p 9000 08:03 4303501/lib/libnss_files-2.11.1.so b7746000-b7747000 rw-p a000 08:03 4303501/lib/libnss_files-2.11.1.so b7747000-b7748000 rw-p 00:00 0 b7748000-b774a000 r-xp 08:03 4328458/lib/libdl-2.11.1.so b774a000-b774b000 r--p 1000 08:03 4328458/lib/libdl-2.11.1.so b774b000-b774c000 rw-p 2000 08:03 4328458/lib/libdl-2.11.1.so b774c000-b788d000 r-xp 08:03 4303498/lib/libc-2.11.1.so b788d000-b788f000 r--p 0014 08:03 4303498/lib/libc-2.11.1.so b788f000-b789 rw-p 00142000 08:03 4303498/lib/libc-2.11.1.so b789-b7893000 rw-p 00:00 0 b7893000-b789e000 r-xp 08:03 17009921 /usr/lib/libfakeroot/fakechroot/libfakechroot.so b789e000-b789f000 rw-p a000 08:03 17009921 /usr/lib/libfakeroot/fakechroot/libfakechroot.so b789f000-b78a rw-p 00:00 0 b78a-b78a1000 r-xp 00:00 0 [vdso] b78a1000-b78bd000 r-xp 08:03 4330037/lib/ld-2.11.1.so b78bd000-b78be000 r--p 0001b000 08:03 4330037/lib/ld-2.11.1.so b78be000-b78bf000 rw-p 0001c000 08:03 4330037/lib/ld-2.11.1.so bffc9000-bffde000 rw-p 00:00 0 [stack] Aborted gdb /bin/true crashes similarly. The bug is caused by the newenvp array overflowing in execve() and can be fixed by replacing i with (i+1) in execve()'s realloc() call. However, I found out that the bug is already fixed in SVN, which makes me concerned that the fix wasn't released yet. If it's because the trunk is unstable at the moment, please consider doing a separate bugfix release. Building software is one of the main uses of fakechroot, and being unable to use gcc (together with FAKECHROOT_EXCLUDE_PATH) seriously reduces its functionality. I am using fakechroot-2.9 compiled from source on ArchLinux. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
