terminated on stack smashing detected message

Bug #370735 reported by Olivier Berger
26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
gmemusage (Ubuntu)
Fix Released
Medium
Unassigned
Declined for Jaunty by Marc Deslauriers
Declined for Karmic by Marc Deslauriers
Natty
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: gmemusage

gmemusage doesn't start, or more precisely briefly displays the window and crashes with the following logs on commandline :
$ gmemusage
*** stack smashing detected ***: gmemusage terminated
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7d9bda8]
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7d9bd60]
gmemusage[0x804b063]
gmemusage[0x8049878]
gmemusage[0x804a7ed]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7cb4775]
gmemusage[0x8049551]
======= Memory map: ========
08048000-0804d000 r-xp 00000000 08:05 278037 /usr/bin/gmemusage
0804d000-0804e000 r--p 00004000 08:05 278037 /usr/bin/gmemusage
0804e000-0804f000 rw-p 00005000 08:05 278037 /usr/bin/gmemusage
08b28000-08b49000 rw-p 08b28000 00:00 0 [heap]
b7c4e000-b7c5b000 r-xp 00000000 08:05 179902 /lib/libgcc_s.so.1
b7c5b000-b7c5c000 r--p 0000c000 08:05 179902 /lib/libgcc_s.so.1
b7c5c000-b7c5d000 rw-p 0000d000 08:05 179902 /lib/libgcc_s.so.1
b7c5d000-b7c61000 r-xp 00000000 08:05 279321 /usr/lib/libXfixes.so.3.1.0
b7c61000-b7c62000 rw-p 00003000 08:05 279321 /usr/lib/libXfixes.so.3.1.0
b7c62000-b7c6a000 r-xp 00000000 08:05 279275 /usr/lib/libXrender.so.1.3.0
b7c6a000-b7c6b000 r--p 00007000 08:05 279275 /usr/lib/libXrender.so.1.3.0
b7c6b000-b7c6c000 rw-p 00008000 08:05 279275 /usr/lib/libXrender.so.1.3.0
b7c6c000-b7c74000 r-xp 00000000 08:05 278089 /usr/lib/libXcursor.so.1.0.2
b7c74000-b7c75000 rw-p 00007000 08:05 278089 /usr/lib/libXcursor.so.1.0.2
b7c75000-b7c76000 rw-p b7c75000 00:00 0
b7c76000-b7c7a000 r-xp 00000000 08:05 279303 /usr/lib/libXdmcp.so.6.0.0
b7c7a000-b7c7b000 rw-p 00003000 08:05 279303 /usr/lib/libXdmcp.so.6.0.0
b7c7b000-b7c7c000 rw-p b7c7b000 00:00 0
b7c7c000-b7c7e000 r-xp 00000000 08:05 279937 /usr/lib/libXau.so.6.0.0
b7c7e000-b7c7f000 r--p 00001000 08:05 279937 /usr/lib/libXau.so.6.0.0
b7c7f000-b7c80000 rw-p 00002000 08:05 279937 /usr/lib/libXau.so.6.0.0
b7c80000-b7c82000 r-xp 00000000 08:05 212609 /lib/tls/i686/cmov/libdl-2.9.so
b7c82000-b7c83000 r--p 00001000 08:05 212609 /lib/tls/i686/cmov/libdl-2.9.so
b7c83000-b7c84000 rw-p 00002000 08:05 212609 /lib/tls/i686/cmov/libdl-2.9.so
b7c84000-b7c9c000 r-xp 00000000 08:05 280154 /usr/lib/libxcb.so.1.1.0
b7c9c000-b7c9d000 r--p 00017000 08:05 280154 /usr/lib/libxcb.so.1.1.0
b7c9d000-b7c9e000 rw-p 00018000 08:05 280154 /usr/lib/libxcb.so.1.1.0
b7c9e000-b7dfa000 r-xp 00000000 08:05 212604 /lib/tls/i686/cmov/libc-2.9.so
b7dfa000-b7dfb000 ---p 0015c000 08:05 212604 /lib/tls/i686/cmov/libc-2.9.so
b7dfb000-b7dfd000 r--p 0015c000 08:05 212604 /lib/tls/i686/cmov/libc-2.9.so
b7dfd000-b7dfe000 rw-p 0015e000 08:05 212604 /lib/tls/i686/cmov/libc-2.9.so
b7dfe000-b7e01000 rw-p b7dfe000 00:00 0
b7e01000-b7eeb000 r-xp 00000000 08:05 278238 /usr/lib/libX11.so.6.2.0
b7eeb000-b7eec000 ---p 000ea000 08:05 278238 /usr/lib/libX11.so.6.2.0
b7eec000-b7eed000 r--p 000ea000 08:05 278238 /usr/lib/libX11.so.6.2.0
b7eed000-b7eef000 rw-p 000eb000 08:05 278238 /usr/lib/libX11.so.6.2.0
b7eef000-b7ef1000 rw-p b7eef000 00:00 0
b7f01000-b7f02000 rw-p b7f01000 00:00 0
b7f02000-b7f03000 r-xp b7f02000 00:00 0 [vdso]
b7f03000-b7f1f000 r-xp 00000000 08:05 179890 /lib/ld-2.9.so
b7f1f000-b7f20000 r--p 0001b000 08:05 179890 /lib/ld-2.9.so
b7f20000-b7f21000 rw-p 0001c000 08:05 179890 /lib/ld-2.9.so
bfc0c000-bfc21000 rw-p bffeb000 00:00 0 [stack]
Abandon

Hope this helps.

affects gmemusage package 0.2-11

Related branches

Olivier Berger (oberger)
description: updated
Revision history for this message
Akkana Peck (akkzilla) wrote :

Same error here. Worked in intrepid, broken in jaunty. Nominating for jaunty since the program doesn't work at all now.

Revision history for this message
emorrp1 (emorrp1) wrote :

I can confirm that this is still an issue in Jaunty, reported from linux mint Gloria: http://forums.linuxmint.com/viewtopic.php?f=166&t=27666

chattr:
"if I ' apt-get remove gmemusage ' and grab the Debian testing/squeeze 0.2-11 i386 package and install that package via ' dpkg -i ', then gmemusage runs fine."

Revision history for this message
Akkana Peck (akkzilla) wrote :

Confirmed, installing the squeeze deb fixes the problem for me as well in jaunty. Curiously, building from the squeeze tarball with patches added still crashes, so I'm not sure what they've changed.

Revision history for this message
Akkana Peck (akkzilla) wrote :

Building the hardy package on hardy with dpkg-buildpackage also results in a binary that gives the stack-smashing error (though the hardy binary package worked fine).

Building with -fno-stack-protector as part of CFLAGS makes it ignore the stack smashing, and the program works again.

My guess (I don't know how to check this) is that the default setting for -fno-stack-protector changed on the machines used to produce jaunty binary packages, relative to the machines used for intrepid packages (but that it didn't change on hardy or intrepid themselves).

But I've found the cause of the problem. gmemusage assumes that the names read from /proc/*/status can fit in 14 characters (including the null), but some of them are actually 15 characters (so 16 with the null). I'm attaching a patch. I've separated the number out into a #define in case it changes again. Is this size documented anywhere, or set in any system include file?

As long as I was making a patch I also fixed a couple of warnings and some unsafe behavior (changed strcpy to strncpy).

Revision history for this message
Akkana Peck (akkzilla) wrote :

Here's a better patch: I fixed one more strcpy and one more warning, and added a field width in the sscanf for procName.

emorrp1 (emorrp1)
Changed in linuxmint:
importance: Undecided → Medium
status: New → In Progress
emorrp1 (emorrp1)
Changed in linuxmint:
status: In Progress → Triaged
Revision history for this message
Akkana Peck (akkzilla) wrote :

Would a debdiff help in getting this patch accepted? I've never made a debdiff but I can try.

Revision history for this message
Julien Lavergne (gilir) wrote :

Thanks for your work on it.
Yes, a debdiff is necessary if you want a sponsor. You can have more details on https://wiki.ubuntu.com/MOTU/Contributing
Also, it would be nice to post this patch to Debian also, they should have the same problem, and we can keep packages in sync.

I unsubscribe ubuntu-universe-sponsors for now, please re-subscribe when you have a debdiff.

Revision history for this message
Menachem Shapiro (menachem) wrote :

This is still an issue in Lucid. I just installed version 0.2-11 in Lucid and got the same error.

Revision history for this message
Akkana Peck (akkzilla) wrote :
Revision history for this message
Chris Coulson (chrisccoulson) wrote :

Hi,

Thanks for working on this. I have a couple of comments though:

- The scope of the patch seems to expand beyond the original bug. Whilst it's perfectly ok for you to fix the additional issues, would you mind splitting those changes in to a separate patch? (I'm referring to the cast you added in draw_window and the prototype change to main() ).

- You hardcode "%15s" in the prototype for sscanf, when you use a constant everywhere else. Why not do something like this?

     char *format ;
     asprintf ( &format , "%%*s %%%ds" , PROCNAMELEN - 1 ) ;
     sscanf ( buf , format , procName ) ;
     free ( format ) ;

(Note that this doesn't make sure asprintf succeeded, which isn't good - but it doesn't look like this application checks that any other call succeeds either, so I'm not sure that matters so much here).

Let me know what you think, but I'd certainly sponsor this once you've addressed the first point

Changed in gmemusage (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Chris Coulson (chrisccoulson) wrote :

There is a typo in my last comment. I should have said "You hardcode "%15s" in the format string for sscanf"

Kees Cook (kees)
Changed in gmemusage (Ubuntu):
status: Triaged → Incomplete
Changed in gmemusage (Ubuntu Natty):
status: New → Incomplete
Revision history for this message
Kees Cook (kees) wrote :

I've updated the debdiff with Chris's suggestions, and fixed up the changelog to use LP-style bug numbering. Thanks for the work on this, I'll get it uploaded shortly.

Changed in gmemusage (Ubuntu):
status: Incomplete → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gmemusage - 0.2-11ubuntu1

---------------
gmemusage (0.2-11ubuntu1) oneiric; urgency=low

  * Add debian/patches/30_stacksmash2.patch: fix stack smashing crash on
    startup (LP: #370735).
 -- Akkana Peck <email address hidden> Wed, 01 Jun 2011 10:02:33 -0700

Changed in gmemusage (Ubuntu):
status: Fix Committed → Fix Released
no longer affects: linuxmint
Revision history for this message
Rolf Leggewie (r0lf) wrote :

natty has seen the end of its life and is no longer receiving any updates. Marking the natty task for this ticket as "Won't Fix".

Changed in gmemusage (Ubuntu Natty):
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.