As you wish solar, i'm filling new bug: # ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 2464 532 ? S 20:25 0:00 init [3] ... root 660 0.0 0.0 0 0 ? S< 20:25 0:00 [ata/0] root 661 0.0 0.0 0 0 ? S 20:25 0:00 [scsi_eh_0] root 662 0.0 0.0 0 0 ? S 20:25 0:00 [scsi_eh_1] root 680 0.0 0.0 0 0 ? S< 20:25 0:00 [reiserfs/0] root 760 0.0 0.2 8100 1208 ? Ss 20:25 0:00 /sbin/devfsd /d root 5148 0.0 0.0 0 0 ? S 20:25 0:00 [khubd] ps: stack smashing attack in function pr_args() Aborted It occurs sometimes, not always, and it's amd64. emerge info: Portage 2.0.51-r3 (default-linux/amd64/2004.3, gcc-3.3.4, glibc-2.3.4.20041021-r0,glibc-2.3.4.20041102-r0, 2.6.9-gentoo x86_64) ================================================================= System uname: 2.6.9-gentoo x86_64 AMD Athlon(tm) 64 Processor 2800+ Gentoo Base System version 1.6.5 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r6 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-march=athlon64 -O2 -pipe -DNDEBUG -DG_DISABLE_ASSERT -s -ffast-math -fomit-frame-pointer -fstack-protector" CHOST="x86_64-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=x86-64 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig autodigest candy ccache cvs distlocks fixpackages sandbox sign" GENTOO_MIRRORS="http://trumpetti.atm.tut.fi/gentoo/ http://ftp.rhnet.is/pub/gentoo/ http://ftp.easynet.nl/mirror/gentoo/ http://gentoo.zie.pg.gda.pl" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="amd64 X acl acpi alsa apache2 avi berkdb bitmap-fonts bzlib cdr crypt cups dga esd f77 fam flac ftp gdbm gif gmp gnome gpm gtk gtk2 imagemagick imap imlib ipv6 jp2 jpeg libwww lzw lzw-tiff maildir mikmod mime mng motif mpeg multilib ncurses nls nptl oggvorbis openal opengl oss pam pdflib perl png posix python readline samba sasl sdl slang spell sqlite ssl tcltk tcpd tiff truetype usb userlocales wxwindows xml xml2 xmms xpm xrandr xsl xv zlib video_cards_radeon linguas_pl"
CFLAGS += -s # (that's not really safe) CFLAGS += -DNDEBUG # (this is not safe either) CFLAGS += -DG_DISABLE_ASSERT # (probably not safe) # as for ps can you recompile procps with CFLAGS="-g3" FEATURES=nostrip ulimit -c unlimited ; when ps drops a 'core' we have something to work with. Feel free to attach the file which contains the function pr_args()
Well I've done everything I can do to try and reproduce this. And I can't if ssp catches it then fbounds shows/tells me what's up. CFLAGS="-fbounds-checking -g3 -march=athlon64 -O2 -pipe -DNDEBUG -DG_DISABLE_ASSERT -s -ffast-math -fomit-frame-pointer" FEATURES="nostrip" emerge procps
This looks like bug #75312. This might be fixed in the CVS tree at SourceForge. A bug was found that involved a function that was called with an (int*) but needed (size_t*). Unfortunately, gcc is unable to warn about this when run on a 32-bit system. The output buffer itself is protected by a guard page.
*** Bug 75312 has been marked as a duplicate of this bug. ***
Albert, can you attach a patch here that we can get Karol Wojtaszek to test? Looking at the ./ps/output.c pr_args() function the only thing that I see that's an int is the function itself so I'm not sure what has to be fixed and I've not looked at the CVS.
The problem is that a function called by pr_args has the wrong prototype. I fixed it by using (int*) in the prototype. This is Debian bug 287947. Patch here: http://sourceforge.net/mailarchive/forum.php?thread_id=6254489&forum_id=12454 This'll be in the next release, out RSN I hope.
This is looking somewhat scary. Anybody know better? On a 32-bit system, nothing interesting happens. On a 64-bit system, effects will depend on... a. endianness b. order of stack variables (in C standard AFAIK) c. position of non-variable stack items (ret addr, tmps, frame ptr...) A 32-bit variable called "rightward" is on the stack in pr_args. This is loaded as a 64-bit variable. If things go well, this will involve an adjacent 32-bit variable called "flags" that will not be used again. Otherwise, it all depends... This value, 32 bits data plus 32 bits junk, is interpreted as the number of character cells left on the line. (1 to 5 UTF-8 bytes will map to 0 to 2 character cells) The value is decremented as output is produced. The final value is then written back via the pointer from which it came, possibly mangling 32 bits of the stack. The maximum value that the initial 32-bit "rightward" variable can have is determined by the number of character cells remaining before end-of-line is reached. In case of unlimited width output, it can start as large as 128*PAGE_SIZE+8*PAGE_SIZE. The value can be decremented to zero, except that it can only decrement by about 2*PAGE_SIZE with an unmodified Linux kernel. So... does anybody know what is getting overwritten with a typical 64-bit compile? The variable declarations look like this: static int pr_args(char *restrict const outbuf, const proc_t *restrict const pp){ char *endp = outbuf; unsigned flags; int rightward=max_rightward; The calls with bad prototypes look like this: endp += escape_command(endp, pp, OUTBUF_SIZE, &rightward, flags); endp += escape_strlist(endp, env, OUTBUF_SIZE, &rightward);
BTW, it would be really nice if somebody could fix up gcc and glibc to provide warnings for this sort of thing. I suppose that means marking the size_t typedef with a newly invented gcc-specific attribute to indicate that the size will vary, and that confusing (size_t*) with (int*) or (long*) would be very bad. I had plenty of warnings enabled, and I got nothing. Grrr. Can you tell I'm bitter? I asked for warnings damn it.
On a little-endian box, some value adjacent to "rightward" can at worst be decremented by one. This is pretty damn unlikely to cause more than a crash, no matter what the compiler does. On a big-endian box, the value can be decremented by PAGE_SIZE at most. (using plain ASCII) Based on the behavior the little-endian box, I'll guess that a big-endian box only smashes a variable that will no longer be used.
sekretarz, Does the patch from comment #6 do the trick for you?
I don't expirience any problems now, and i can't test this patch. I even can reproduce this bug it's wired
s/can/can't/
OK, i have done some tricky things and reproduced bug, patch really works. I'll attach patch prepared to portage Thanks for help
Created attachment 48664 [details, diff] Patch prepared to working with portage
*** Bug 79533 has been marked as a duplicate of this bug. ***
Created attachment 49532 [details, diff] procps-3.2.4-r1.ebuild save attachment #48664 [details, diff] as files/3.2.4-escape_strlist.patch and this ebuild. ebuild procps-3.2.4-r1.ebuild digest emerge =sys-apps/procps-3.2.4-r1 and submit feedback trelane.
the behavior of strace has not changed, I am including attachments of strace output of ps aux, and stdin output of ps ps u ps x and ps aux
Created attachment 49533 [details] this is stdout output of ps with various options demonstrating the bug
Created attachment 49534 [details] this is an strace of ps aux
sekretarz what do you want todo here? patch works for you and you reported the bug. user reports patch does not solve problem for them and pr_args() problems continues. I don't own an amd64 and am unable to verify any problems mentioned in this bug. I can only confirm that on amd64 the procps package works with a USE="-multilib hardened" toolchain enabled without any "-fstack-protector" in the CFLAGS.
this now appears to work in portage with "-r2"
Not for me it doesn't.
reopen if needed.
