Description of problem: After upgrading to F12, running star to create a backup always results in a crash, reporting a buffer overflow (selinux: enforcing, targeted-policy) Version-Release number of selected component (if applicable): star-1.5-8.fc12.x86_64 How reproducible: always Steps to Reproduce: 1. run (as root): star -c -H=exustar -xattr -file=/mnt/bak/87.106.208.227-_-20100119004527.star.bz2 -xdev -FFF -j -C / . 2. wait approx 1 min. 3. Actual results: After writing approx 40MB of data to the specified archive, star crashes with the following message: *** buffer overflow detected ***: star terminated ======= Backtrace: ========= /lib64/libc.so.6(__fortify_fail+0x37)[0x39826f75e7] /lib64/libc.so.6[0x39826f5600] star[0x424c90] star[0x415fc6] star[0x416cb6] ======= Memory map: ======== 00400000-0044c000 r-xp 00000000 09:02 256855 /usr/bin/star 0064b000-0064e000 rw-p 0004b000 09:02 256855 /usr/bin/star 0064e000-00672000 rw-p 00000000 00:00 0 0084d000-0084f000 rw-p 0004d000 09:02 256855 /usr/bin/star 00bbc000-00bdd000 rw-p 00000000 00:00 0 [heap] 3982200000-398221e000 r-xp 00000000 09:01 117000 /lib64/ld-2.11.1.so 398241d000-398241e000 r--p 0001d000 09:01 117000 /lib64/ld-2.11.1.so 398241e000-398241f000 rw-p 0001e000 09:01 117000 /lib64/ld-2.11.1.so 398241f000-3982420000 rw-p 00000000 00:00 0 3982600000-398276f000 r-xp 00000000 09:01 117001 /lib64/libc-2.11.1.so 398276f000-398296f000 ---p 0016f000 09:01 117001 /lib64/libc-2.11.1.so 398296f000-3982973000 r--p 0016f000 09:01 117001 /lib64/libc-2.11.1.so 3982973000-3982974000 rw-p 00173000 09:01 117001 /lib64/libc-2.11.1.so 3982974000-3982979000 rw-p 00000000 00:00 0 3982e00000-3982e02000 r-xp 00000000 09:01 117007 /lib64/libdl-2.11.1.so 3982e02000-3983002000 ---p 00002000 09:01 117007 /lib64/libdl-2.11.1.so 3983002000-3983003000 r--p 00002000 09:01 117007 /lib64/libdl-2.11.1.so 3983003000-3983004000 rw-p 00003000 09:01 117007 /lib64/libdl-2.11.1.so 3983a00000-3983a1c000 r-xp 00000000 09:01 117058 /lib64/libselinux.so.1 3983a1c000-3983c1b000 ---p 0001c000 09:01 117058 /lib64/libselinux.so.1 3983c1b000-3983c1c000 r--p 0001b000 09:01 117058 /lib64/libselinux.so.1 3983c1c000-3983c1d000 rw-p 0001c000 09:01 117058 /lib64/libselinux.so.1 3983c1d000-3983c1e000 rw-p 00000000 00:00 0 3984600000-3984616000 r-xp 00000000 09:01 117055 /lib64/libgcc_s-4.4.2-20091222.so.1 3984616000-3984815000 ---p 00016000 09:01 117055 /lib64/libgcc_s-4.4.2-20091222.so.1 3984815000-3984816000 rw-p 00015000 09:01 117055 /lib64/libgcc_s-4.4.2-20091222.so.1 3986200000-3986207000 r-xp 00000000 09:01 117064 /lib64/libacl.so.1.1.0 3986207000-3986407000 ---p 00007000 09:01 117064 /lib64/libacl.so.1.1.0 3986407000-3986408000 rw-p 00007000 09:01 117064 /lib64/libacl.so.1.1.0 3986600000-3986604000 r-xp 00000000 09:01 117060 /lib64/libattr.so.1.1.0 3986604000-3986803000 ---p 00004000 09:01 117060 /lib64/libattr.so.1.1.0 3986803000-3986804000 rw-p 00003000 09:01 117060 /lib64/libattr.so.1.1.0 7f3f8cfbb000-7f3f8cfc7000 r-xp 00000000 09:01 117054 /lib64/libnss_files-2.11.1.so 7f3f8cfc7000-7f3f8d1c6000 ---p 0000c000 09:01 117054 /lib64/libnss_files-2.11.1.so 7f3f8d1c6000-7f3f8d1c7000 r--p 0000b000 09:01 117054 /lib64/libnss_files-2.11.1.so 7f3f8d1c7000-7f3f8d1c8000 rw-p 0000c000 09:01 117054 /lib64/libnss_files-2.11.1.so 7f3f8d1c8000-7f3f8d9ce000 rw-s 00000000 00:08 2097363 /dev/zero (deleted) 7f3f8d9ce000-7f3f8d9d2000 rw-p 00000000 00:00 0 7f3f8d9e2000-7f3f8d9e4000 rw-p 00000000 00:00 0 7fff891db000-7fff89218000 rw-p 00000000 00:00 0 [stack] 7fff893f7000-7fff893f8000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Expected results: star does not crash Additional info: selinux settings are pretty much standard. I tried enabling allow_execheap and allow_execmod without succes (exacly same crash-report) -Fritz
Thanks for report, fortify fails buffer overflows in F-11/F-12 are usually caused by new fortify_sources checks in glibc/gcc - previously valid source code now crashes. I'll try to check that one. Btw. in F-12 there is nice tool ABRT for reporting such issues/crash bug reports - it tries to download required debuginfo packages which makes the backtrace much more useful.
Sorry for missing that (this is a stripped-down server installation (specifically: without a running dbus - which AFAIK is required by abrtd). However in the meantime, i installed the relevant debuginfo and ran a gdm session manually. Attached is a gzipped screenlog of that gdb session. This reveals the bug: Apparently there are some remnants in the code from the old tar days where the path limit was still 100 chars. As soon as a file with a path length > 100 chars (in this specific case: 101 chars) is to be archived, the bug hits.
Created attachment 385387 [details] screenlog of a gdb session
Oops, typo in my previous message: s/gdm/gdb/
.. And another mistake by me: the path in question is *exactly* 100 chars, *not* 101....
Ok, I could reproduce it. You are right - star (in longnames.c) is trying to copy shortname (100 chars of path) to the buffer - which is only 100 bytes - so the null terminator seems to cause buffer overflow in the case of files with the length 100+. Just fixing this off-by-one issue seems to solve the problem, but I would like to check it a bit more to see if my patch is really good way to solve the problem.
Created attachment 385409 [details] Patch to fix buffer overflow for files with length = 100 This is the patch which is fixing the buffer overflow issue for me. But I have to check if it is correct way to solve the issue.
I'm rebuilding the RPM here with this patch right now. I'll let you know how it works out on my machine later ...
Ok, looks good. Complete backup of 200G finished without any prob. Thanks for the fast response and fix. -Fritz
Thanks for confirmation of the fix - I'll check it for some corner cases to ensure myself that it is not breaking some functionality / bringing some regression and then I'll make star update.
What is the status of this? I seem to be hitting it repeatedly - I checked one of the files it hit just before crashing and it's exactly 100 characters.
Patch fixing issue for startype headers is attached to that bugzilla ... but that's possibly not the right way to fix the issue. Problem is that for pax, ustar, suntar, xstar, xustar, exustar, star have the limit for shortname the same as the buffer size - which causes buffer overflow with new glibc fortify_sources checks. Formats gnutar, tar a v7tar header types should be safe without my patch - as they have 99+XXX format. However - they are affected by my patch - as I fix off-by-one problem even for them - which causes longname complains for 99 chars long name which is completely valid. The names should be split 100(+155 usually) in star-type formats. Buffer for shortname is 100 bytes - therefore with length 100 you have no \0 terminator there - and strcpy just causes buffer overflow error. Probably using strncpy should be better way of solving that issue, but I have to check if it works correctly for all the formats (current patch does not and changes to headers would mean breaking specifications)...
star-1.5-9.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/star-1.5-9.fc12
Created attachment 388531 [details] Patch to fix the buffer overflow.
star-1.5-9.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update star'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1424
star-1.5-9.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.