Bug 160671 - Random Buffer Overflows
Random Buffer Overflows
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: grip (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Reber
Fedora Extras Quality Assurance
:
: 165005 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-16 11:04 EDT by Benjamin Bach
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: grip-3.2.0-6.fc4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-04 14:19:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for one buffer overflow in id3.c (373 bytes, patch)
2005-08-03 20:25 EDT, Michael Schwendt
no flags Details | Diff
Backtrace of ID3 v2 writing buffer overflow (6.53 KB, text/plain)
2005-08-04 12:05 EDT, Need Real Name
no flags Details

  None (edit)
Description Benjamin Bach 2005-06-16 11:04:45 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
I get this giant buffer overflow when ripping. It occurs at random times in the beginning of the ripping process (track 1-3 of an 11 track cd). My FC4 is a fresh install.

Also Grip often completely fails ripping because of this:

Error trying to open /dev/hdd exclusively (Device or resource busy). retrying in 1 second.

Then later it will crash with the usual buffer overflow:

*** buffer overflow detected ***: grip terminated
======= Backtrace: =========
/lib/libc.so.6(__chk_fail+0x41)[0xec8565]
/lib/libc.so.6(__vsprintf_chk+0x0)[0xec7e30]
/lib/libc.so.6(_IO_default_xsputn+0x97)[0xe4ab58]
/lib/libc.so.6(_IO_vfprintf+0xd92)[0xe25af4]
/lib/libc.so.6(__vsprintf_chk+0xa1)[0xec7ed1]
/lib/libc.so.6(__sprintf_chk+0x30)[0xec7e24]
grip(ID3v2TagFile+0x2a0)[0x8063ea0]
grip(UpdateRipProgress+0x1096)[0x8062a06]
grip(GripUpdate+0xcc)[0x804fd28]
grip[0x804f31c]
/usr/lib/libglib-2.0.so.0[0x30ef06]
/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1dc)[0x30d3ee]
/usr/lib/libglib-2.0.so.0[0x3103f6]
/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1a1)[0x3106e3]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb4)[0x64b1b5]
grip(Cmain+0x22c)[0x804f29b]
/lib/libc.so.6(__libc_start_main+0xc6)[0xdfede6]
grip[0x804ef91]
======= Memory map: ========
00111000-00123000 r-xp 00000000 03:05 1460009    /usr/lib/libz.so.1.2.2.2
00123000-00124000 rwxp 00011000 03:05 1460009    /usr/lib/libz.so.1.2.2.2
00124000-00185000 r-xp 00000000 03:05 1460018    /usr/lib/libfreetype.so.6.3.7
00185000-0018c000 rwxp 00061000 03:05 1460018    /usr/lib/libfreetype.so.6.3.7
0018c000-001b2000 r-xp 00000000 03:05 1460020    /usr/lib/libfontconfig.so.1.0.4001b2000-001b5000 rwxp 00026000 03:05 1460020    /usr/lib/libfontconfig.so.1.0.4001b5000-001b6000 rwxp 001b5000 00:00 0
001b6000-001b7000 r-xp 00000000 03:05 1598576    /usr/X11R6/lib/X11/locale/lib/common/xlcUTF8Load.so.2
001b7000-001b8000 rwxp 00000000 03:05 1598576    /usr/X11R6/lib/X11/locale/lib/common/xlcUTF8Load.so.2
001b8000-001ca000 r-xp 00000000 03:05 1460021    /usr/X11R6/lib/libXft.so.2.1.2
001ca000-001cb000 rwxp 00012000 03:05 1460021    /usr/X11R6/lib/libXft.so.2.1.2
001cb000-001dc000 r-xp 00000000 03:05 1449262    /usr/lib/libcdda_interface.so.0.9.8
001dc000-001dd000 rwxp 00011000 03:05 1449262    /usr/lib/libcdda_interface.so.0.9.8
001dd000-001e4000 r-xp 00000000 03:05 1452110    /usr/lib/libcdda_paranoia.so.0.9.8
001e4000-001e5000 rwxp 00007000 03:05 1452110    /usr/lib/libcdda_paranoia.so.0.9.8
001e5000-001ec000 r-xp 00000000 03:05 1460035    /usr/lib/libpopt.so.0.0.0
001ec000-001ed000 rwxp 00006000 03:05 1460035    /usr/lib/libpopt.so.0.0.0
001ed000-001ef000 r-xp 00000000 03:05 621895     /lib/libcom_err.so.2.1
001ef000-001f0000 rwxp 00001000 03:05 621895     /lib/libcom_err.so.2.1
001f2000-002a6000 r-xp 00000000 03:05 1454020    /usr/lib/libvte.so.4.4.0
002a6000-002af000 rwxp 000b3000 03:05 1454020    /usr/lib/libvte.so.4.4.0
002af000-002d5000 r-xp 00000000 03:05 1460066    /usr/lib/libgnomecanvas-2.so.0.1000.0
002d5000-002d8000 rwxp 00025000 03:05 1460066    /usr/lib/libgnomecanvas-2.so.0.1000.0
002d8000-002da000 r-xp 00000000 03:05 1460028    /usr/lib/libkrb5support.so.0.0
002da000-002db000 rwxp 00001000 03:05 1460028    /usr/lib/libkrb5support.so.0.0
002db000-002de000 r-xp 00000000 03:05 1460015    /usr/X11R6/lib/libXrandr.so.2.0002de000-002df000 rwxp 00002000 03:05 1460015    /usr/X11R6/lib/libXrandr.so.2.0002df000-002e7000 r-xp 00000000 03:05 1460023    /usr/X11R6/lib/libSM.so.6.0
002e7000-002e8000 rwxp 00007000 03:05 1460023    /usr/X11R6/lib/libSM.so.6.0
002ea000-0036e000 r-xp 00000000 03:05 1448594    /usr/lib/libglib-2.0.so.0.600.40036e000-00373000 rwxp 00084000 03:05 1448594    /usr/lib/libglib-2.0.so.0.600.400375000-0038c000 r-xp 00000000 03:05 1460022    /usr/X11R6/lib/libICE.so.6.3
0038c000-0038d000 rwxp 00016000 03:05 1460022    /usr/X11R6/lib/libICE.so.6.3
0038d000-0038f000 rwxp 0038d000 00:00 0
0038f000-003a0000 r-xp 00000000 03:05 1460071    /usr/lib/libbonobo-activation.so.4.0.0
003a0000-003a3000 rwxp 00010000 03:05 1460071    /usr/lib/libbonobo-activation.so.4.0.0
003a3000-003ac000 r-xp 00000000 03:05 621891     /lib/libgcc_s-4.0.0-20050520.so.1
003ac000-003ad000 rwxp 00009000 03:05 621891     /lib/libgcc_s-4.0.0-20050520.so.1
003ad000-003af000 r-xp 00000000 03:05 1460017    /usr/X11R6/lib/libXinerama.so.1.0
003af000-003b0000 rwxp 00001000 03:05 1460017    /usr/X11R6/lib/libXinerama.so.1.0
003b2000



Version-Release number of selected component (if applicable):
grip-3.2.0-4

How reproducible:
Always

Steps to Reproduce:
1. Open Grip
2. Try To rip a Fugazi CD
3.
  

Additional info:
Comment 1 Adrian Reber 2005-06-16 13:08:22 EDT
Does this happen with every CD you try to rip, or does it only occur with
certain CDs?
Could it be that your harddisk is full and it crashes therefore somewhere?
Do you have the debuginfo for grip installed?
Have you contacted upstream?

As I cannot reprodruce it I am currently only guessing...
Comment 2 Benjamin Bach 2005-06-26 05:46:56 EDT
Yes, it happens with all my CDs drive. HDD isn't full but I'm writing to a FAT32
partition. Maybe that's the problem. I will try to install the debug and get back.
Comment 3 Adrian Reber 2005-08-03 10:50:54 EDT
*** Bug 165005 has been marked as a duplicate of this bug. ***
Comment 4 Need Real Name 2005-08-03 13:08:00 EDT
Why the heck couldn't I find this bug when I searched extensively!  Same problem
here and my duplicate report bug 165005 contains most of my information. I'm
also ripping to a FAT32 partition, but previously (FC3) grip ripped to it fine.
Hard disk nowhere near full.

To answer Adrian's question on the other bug - just renamed ~/.grip so it's
ripping to ogg by default and to ext3: no crash. Changed new config to rip to
ogg on FAT32 - no crash. Changed ripper from new default of cdparanoia back to
my previous setting of cdda2wav - no crash writing to either filesystem. In
short, I've done about 30 rips and encodes varying every variable and think I've
found at least one hot-point causing a crash every time:

doid3v2 1 (Add ID3v2 tags to encoded files)

when writing the mp3 to *either* filesystem (FAT32 or ext3). Turning
no_lower_case, no_underscore and allow_high_bits don't make any difference - it
crashes with them on or off. I don't have any allow_these_chars set and am using
the default UTF-8 settings. And the crash occurs right at the end of the
encoding phase, just when the tags will be being written. Or presumably when the
.wav is being deleted, but I've disabled this and the crash still occurs. Just
to emphasise, the filesystem is irrelevant at least for this crash.

The odd thing is that there's nothing special about the problematic tracks, yet
the crashes are predictable with it.  No foreign language accents in grip, nor
do they have when viewed at freedb.org.

I don't have the debuginfo package installed (do I have to rebuild the SRPM to
get this, or is it in a repository?). Done a lot of debugging on this today so I
have to stop for now - maybe Benjamin could try and reproduce this or this
provides some more clues to Adrian. If it's relevant:

% rpm -q taglib taglib-devel
taglib-1.4-1.fc4
taglib-devel-1.4-1.fc4

So for now my workaround: turn off ID3 v2 tagging, and write them with easytag
later. Of course there may be other case crashes with this turned off - I'll try
to add to this bugzilla if I find them.

My hardware (although probably irrelevant):
Probing IDE interface ide1...
hdc: UJDA755zDVD/CDRW, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
Comment 5 Michael Schwendt 2005-08-03 20:13:38 EDT
Yes, debuginfo packages are found in the Fedora Extras repository, ./debug
sub-directory. A full backtrace -- http://fedoraproject.org/wiki/StackTraces --
would be interesting, since you seem to be able to reproduce this crash.

taglib is not used here.

libid3 is used, so grip-debuginfo and libid3-debuginfo should be installed at least.
Comment 6 Michael Schwendt 2005-08-03 20:25:52 EDT
Created attachment 117424 [details]
patch for one buffer overflow in id3.c

This is one sprintf buffer overflow in grip's ID3v2 creation.
Comment 7 Need Real Name 2005-08-04 10:38:01 EDT
Thanks Michael - I've applied your patch to the current SRPM and rebuilt it, and
it certainly seems to fix the specific ID3 v2 writing overflows above - can't
reproduce them for now.  I'd suggest leaving this bug open for a while to allow
Benjamin and any others to confirm his settings - this may not be the only problem.

Will install debuginfos if I get more crashes.
Comment 8 Adrian Reber 2005-08-04 11:08:24 EDT
Michael, thanks for your help. I will apply the patch and release a new package
today.
Comment 9 Need Real Name 2005-08-04 12:03:17 EDT
Hmm. Two system hangs (complete, not even responsive to SysRq) using the patched
grip. Syslog messages:
Aug  4 14:57:39 localhost kernel: hdc: DMA timeout retry
Aug  4 14:57:39 localhost kernel: hdc: timeout waiting for DMA
Aug  4 14:57:39 localhost kernel: hdc: status error: status=0x58 { DriveReady
SeekComplete DataRequest }
Aug  4 14:57:39 localhost kernel: ide: failed opcode was: unknown
Aug  4 14:57:39 localhost kernel: hdc: drive not ready for command

Restored the current unpatched Extras grip and no hangs. Feasible that the patch
could cause this?

Back to the original grip, with debuginfo packages installed (I assume you meant
libid3tag):

% rpm -q grip grip-debuginfo libid3tag libid3tag-debuginfo
grip-3.2.0-5.fc4
grip-debuginfo-3.2.0-5.fc4
libid3tag-0.15.1-3.b
libid3tag-debuginfo-0.15.1-3.b

- backtrace attached next.
Comment 10 Need Real Name 2005-08-04 12:05:37 EDT
Created attachment 117460 [details]
Backtrace of ID3 v2 writing buffer overflow
Comment 11 Michael Schwendt 2005-08-04 12:56:40 EDT
* libid3tag is not used by grip, id3lib is.

* The patch does not cause any hangs. It does not introduce any regression and
does not have any effect onto the kernel/driver level.

> comment=0x8e4b9d8 "", genre=131 '\203', tracknum=5 '\005',

Thanks for the more detailed bracktrace. The "genre" value in there (three
digits wide) confirms that the patch fixes the buffer overflow.
Comment 12 Michael Schwendt 2005-08-04 13:05:25 EDT
Also found upstream:

  Grip crashes after one track is ripped but not for all CDs
 
https://sourceforge.net/tracker/index.php?func=detail&aid=1238430&group_id=3714&atid=103714

Also patched in exactly the same way:

  ID3v2TagFile() insufficient genre buffer size bugfix
 
http://sourceforge.net/tracker/index.php?func=detail&aid=1013980&group_id=3714&atid=303714

Comment 13 Need Real Name 2005-08-04 14:06:02 EDT
Hmm thanks. So my lockups were coincidental, possibly hardware?  I can see the
sense in your patch, harmless and can't cause a lockup - but experienced two in
3 CDs and never have before, and none again having restored the Extras RPM. 
Wondering if there's another bug in grip which your fix clears the way for...
will report back here if I see more.
Comment 14 Adrian Reber 2005-08-04 14:19:42 EDT
I was finally able to reproduce this error. The important part is to select
'Indie' as genre and then it crashes. The patch fixes the error for me.

I have requested a new build of grip with this patch included and a new version
will be available shortly and I will close this bug.
If you still have the same problem then just re-open the bug.
For kernel hangs you should open another bug.

Note You need to log in before you can comment on or make changes to this bug.