Bug 504488 – dev-libs/libburn - buffer overflow in libburn/write.c:1174

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Richard Goedeken 2014-03-13 14:32:56 UTC]

I burned about 10 coasters before I finally tracked down and fixed this bug in libburn-1.3.4.  It also happens in 1.3.2 and 1.3.6.  By running Brasero with debugging info turned on, I saw this backtrace:

*** buffer overflow detected ***: brasero terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x47)[0x7fc51899c2e7]
/lib64/libc.so.6(+0x102150)[0x7fc51899a150]
/lib64/libc.so.6(+0x1015c9)[0x7fc5189995c9]
/lib64/libc.so.6(__printf_fp+0x1d00)[0x7fc5188e98e0]
/lib64/libc.so.6(_IO_vfprintf+0x113d)[0x7fc5188e35dd]
/lib64/libc.so.6(__vsprintf_chk+0x82)[0x7fc518999662]
/lib64/libc.so.6(__sprintf_chk+0x7d)[0x7fc51899959d]
/usr/lib64/libburn.so.4(+0x3135b)[0x7fc4f06d735b]
/usr/lib64/libburn.so.4(+0x31597)[0x7fc4f06d7597]
/usr/lib64/libburn.so.4(+0x34b83)[0x7fc4f06dab83]
/usr/lib64/libburn.so.4(+0xa412)[0x7fc4f06b0412]
/lib64/libpthread.so.0(+0x901a)[0x7fc518c5001a]
/lib64/libc.so.6(clone+0x6d)[0x7fc5189861ad]

This was generated by using a build that I made with debug symbols enabled.  So I used 'addr2line' to get the track down the offending culprit in libburn.so.4 and it reported this:

pyro@DualCore64 ~/Desktop/temp-libburn/libburn-1.3.4 $ addr2line -e /usr/lib64/libburn.so.4 -a 0x3135b
0x000000000003135b
/home/pyro/Desktop/temp-libburn/libburn-1.3.4/libburn/write.c:1174

Looking at this source file (write.c), I can see an sprintf function writing data into a buffer defined as 'char msg[80]'.  By looking at the format string, you can see that there are cases for which this buffer is too small.  It seems silly to try and save a few bytes on the stack at a cost of possibly crashing and ruining CDRs, so I changed all of the "char msg[**]" definitions in this source file to "char msg[256]".  Problem solved; now I can burn CDs again.

Reproducible: Always

Steps to Reproduce:
This bug showed up for me when burning a particular track of a particular audio CD.  It is dependent upon the values of some numbers being written to the message buffer, so it won't happen with every CD burning operation.  It is also caused by libc detecting the buffer overflow and throwing a signal, so it may also depend upon the installed libc.  However I reproduced this problem with 2 different burning programs (brasero and xfburn), and 2 different drives, so I know libburn was the cause of the problem.  Also, I was able to successfully burn the audio CD after applying the fix described above.
Actual Results:  
Consistent disc burning failure in brasero and xfburn after burning 7 tracks (236 MB) of a particular audio CD.

Expected Results:  
It should have completed burning the CD without throwing a signal due to a buffer overflow.

[Comment 1 Jeroen Roovers (RETIRED) 2014-03-13 17:41:38 UTC]

(In reply to Richard Goedeken from comment #0)
> I burned about 10 coasters before I finally tracked down and fixed this bug
> in libburn-1.3.4.  It also happens in 1.3.2 and 1.3.6.

It's not about 1.3.4 then.

[Comment 2 Daniel Pielmeier 2014-03-14 09:00:16 UTC]

I have contacted the upstream developer and he confirmed the bug.

I forward his comments here:
-------------------------------------------------------------
The bug is confirmed and will be fixed soon.
It happens only with CD TAO.
So a workaround is to select write type "SAO".
Thank you for finding this bug which was introduced by
libburn-0.3.4 seven years ago.
-------------------------------------------------------------

[Comment 3 Daniel Pielmeier 2014-03-14 20:42:14 UTC]

+  14 Mar 2014; Daniel Pielmeier <[e-mail]> libburn-1.3.4.ebuild,
+  libburn-1.3.6.ebuild, +files/libburn-1.3.6-buffer-overflow.patch:
+  Add patch to prevent a buffer overflow in libburn/write.c which may occur for
+  certain tracks when trying to burn a CD in TAO mode. Thanks to Richard
+  Goedeken for the report (bug #504488) and proposed patch. Additional thanks
+  go to upstream   author Thomas Schmitt for his quick response regarding the
+  issue.

This is fixed in libburn-1.3.4 and libburn-1.3.6. Thanks again for the detailed bug report and the proposed solution.