The overflow is in file main.c line 200: buf[bufsize] = '\0'; The \0 is written 1 byte after the buffers available space. So it should be changed to: buf[bufsize-1] = '\0'; This led me to the following problem: The following call to eat_file() in qlop.c`s show_current_emerge() manipulated the local pointer DIR *proc... 364 if (!eat_file(path, buf, sizeof(buf))) 365 continue; ..which led to an invalid free at closedir(proc) on line 428 (qlop.c). Reproducible: Always Steps to Reproduce:
thanks, ive fixed the buffer overflow http://sources.gentoo.org/gentoo-projects/portage-utils/main.c?r1=1.173&r2=1.174 but i dont see any problem with the qlop code. the handling of the DIR *proc handle is not related to any of the code inside of the while loop. /proc gets opened (and we check the return), then we walk it via readdir() in the while(), and then after the while() has exited, we closedir() the handle. once it has been opened, it must be closed, and we only close it once. so the handle is always valid here.
with the fix, there is no problem with the qlop code now.. so just for clarification: in qlops show_current_emerge you have some local variables, such as DIR *proc and char buf[BUFSIZE]. on my machine the overflow in eat_file manipulated *proc (set one byte to 0). this was the result: (sry forgot in the first report to post this) *** glibc detected *** ./q: free(): invalid pointer: 0x0000000000645000 *** ======= Backtrace: ========= /lib/libc.so.6[0x7f75bdd3f808] /lib/libc.so.6(cfree+0x6c)[0x7f75bdd4424c] /lib/libc.so.6(closedir+0xd)[0x7f75bdd6808d] ./q[0x410b1a] ./q[0x410de2] ./q[0x409742] ./q[0x409008] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f75bdceaa26] ./q(strstr+0x351)[0x4024f9] ======= Memory map: ======== 00400000-0042c000 r-xp 00000000 08:04 2212002 /home/ben/tmp/portageutils/portage-utils-0.3.1/q 0062b000-0062c000 r--p 0002b000 08:04 2212002 /home/ben/tmp/portageutils/portage-utils-0.3.1/q 0062c000-00639000 rw-p 0002c000 08:04 2212002 /home/ben/tmp/portageutils/portage-utils-0.3.1/q 00639000-00666000 rw-p 00000000 00:00 0 [heap] 7f75b8000000-7f75b8021000 rw-p 00000000 00:00 0 7f75b8021000-7f75bc000000 ---p 00000000 00:00 0 7f75bdab5000-7f75bdacb000 r-xp 00000000 08:04 1721409 /lib64/libgcc_s.so.1 7f75bdacb000-7f75bdcca000 ---p 00016000 08:04 1721409 /lib64/libgcc_s.so.1 7f75bdcca000-7f75bdccb000 r--p 00015000 08:04 1721409 /lib64/libgcc_s.so.1 7f75bdccb000-7f75bdccc000 rw-p 00016000 08:04 1721409 /lib64/libgcc_s.so.1 7f75bdccc000-7f75bde1b000 r-xp 00000000 08:04 1721869 /lib64/libc-2.10.1.so 7f75bde1b000-7f75be01b000 ---p 0014f000 08:04 1721869 /lib64/libc-2.10.1.so 7f75be01b000-7f75be01f000 r--p 0014f000 08:04 1721869 /lib64/libc-2.10.1.so 7f75be01f000-7f75be020000 rw-p 00153000 08:04 1721869 /lib64/libc-2.10.1.so 7f75be020000-7f75be025000 rw-p 00000000 00:00 0 7f75be025000-7f75be042000 r-xp 00000000 08:04 1721835 /lib64/ld-2.10.1.so 7f75be205000-7f75be207000 rw-p 00000000 00:00 0 7f75be23e000-7f75be241000 rw-p 00000000 00:00 0 7f75be241000-7f75be242000 r--p 0001c000 08:04 1721835 /lib64/ld-2.10.1.so 7f75be242000-7f75be243000 rw-p 0001d000 08:04 1721835 /lib64/ld-2.10.1.so 7fff5bf72000-7fff5bf94000 rw-p 00000000 00:00 0 [stack] 7fff5bfa6000-7fff5bfa7000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] original pointer adress of proc: 0x645010 after eat_file it was 0x645000. but as I said this problem doesnt anylonger exist...
