Description of problem: When launching rawtherapee it immediately aborts with glibc fortify source detecting a buffer overflow (gdb) bt #0 0x00007f11eeae08c7 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x00007f11eeae252a in __GI_abort () at abort.c:89 #2 0x00007f11eeb24513 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7f11eec327a9 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x00007f11eebbe307 in __GI___fortify_fail (msg=msg@entry=0x7f11eec3274f "buffer overflow detected") at fortify_fail.c:31 #4 0x00007f11eebbc480 in __GI___chk_fail () at chk_fail.c:28 #5 0x00007f11f580bcb2 in DCraw::get2() (__len=18446744073634054144, __src=<optimized out>, __dest=0x7fffff60d520) at /usr/include/bits/string3.h:51 #6 0x00007f11f580bcb2 in DCraw::get2() (f=0x20bcbb0, count=2, es=1, dst=0x7fffff60d520) at /usr/src/debug/rawtherapee-4.1/rtengine/myfile.h:106 #7 0x00007f11f580bcb2 in DCraw::get2() (this=this@entry=0x7fffff60db20) at /usr/src/debug/rawtherapee-4.1/rtengine/dcraw.cc:276 #8 0x00007f11f582cf9d in DCraw::identify() (this=0x7fffff60db20) at /usr/src/debug/rawtherapee-4.1/rtengine/dcraw.cc:7664 #9 0x00007f11f58641ad in rtengine::RawImage::loadRaw(bool, bool, rtengine::ProgressListener*, double) (this=0xe91, this@entry=0x7fffff60db20, loadData=145, loadData@entry=false, closeFile=6, closeFile@entry=true, plistener=0xffffffffffffffff, plistener@entry=0x0, progressRange=7.0632744564452601e-304, progressRange@entry=1) at /usr/src/debug/rawtherapee-4.1/rtengine/rawimage.cc:256 #10 0x00007f11f585a3e7 in rtengine::DFManager::addFileInfo(Glib::ustring const&, bool) (this=this@entry=0xa3bbc0 <rtengine::dfm>, filename=..., pool=pool@entry=true) at /usr/src/debug/rawtherapee-4.1/rtengine/dfmanager.cc:262 #11 0x00007f11f585c400 in rtengine::DFManager::init(Glib::ustring) (this=0xa3bbc0 <rtengine::dfm>, pathname=...) at /usr/src/debug/rawtherapee-4.1/rtengine/dfmanager.cc:225 #12 0x00007f11f58a61bf in rtengine::init(rtengine::Settings const*, Glib::ustring, Glib::ustring) (s=s@entry=0xa3e218 <options+600>, baseDir=..., userSettingsDir=...) at /usr/src/debug/rawtherapee-4.1/rtengine/init.cc:55 #13 0x0000000000662558 in Options::load() () at /usr/src/debug/rawtherapee-4.1/rtgui/options.cc:1284 #14 0x000000000048afea in main(int, char**) (argc=1, argv=0x7fffff663fd8) at /usr/src/debug/rawtherapee-4.1/rtgui/main.cc:143 Version-Release number of selected component (if applicable): rawtherapee-4.1-2.fc21.x86_64 How reproducible: Always Steps to Reproduce: 1. rawtherapee 2. 3. Actual results: Kaboom Expected results: Presumably it should display some kind of user interface :-)
Hmmm fwiw rawtherapee-4.1-2.fc22.x86_64 is working for me on Rawhide.
Ah ha, so with strace I can see that it is busy trying to read some files in my home directory before it displays its UI. In particular it is opening a Fedora disk image I have for Fedora ARM and probably thinking it is a raw image file :-) So this points to some unsafe image loading code having an assumption violated open("Fedora-Xfce-armhfp-21-20141024-sda.raw", O_RDONLY) = 6 fstat(6, {st_mode=S_IFREG|0664, st_size=4219469824, ...}) = 0 mmap(NULL, 4219469824, PROT_READ, MAP_PRIVATE, 6, 0) = 0x7f563c800000 open("/dev/tty", O_RDWR|O_NOCTTY|O_NONBLOCK) = 10 writev(10, [{"*** ", 4}, {"buffer overflow detected", 24}, {" ***: ", 6}, {"rawtherapee", 11}, {" terminated\n", 12}], 5*** buffer overflow detected ***: rawtherapee terminated ) = 57
If I go to stack frame 6 #6 fread (f=0x20bcbb0, count=2, es=1, dst=0x7fffff60d520) at /usr/src/debug/rawtherapee-4.1/rtengine/myfile.h:106 106 memcpy (dst, f->data+f->pos, avail); Lets look at value of 'avail' (gdb) print avail $6 = -75497472 Yes, that's pretty clearly why glibc is aborting the program. You can't memcpy a negative amount of data :-) The avail variable is initialized from int avail = f->size - f->pos; These two fields have the right value: (gdb) print f->size $7 = 4219469824 (gdb) print f->pos $8 = 0 So what's happening here is that we have a ~4GB file, and when the fread() function calculates the available data it is uses two variables that are declared ssize_t (and thus 64bit) and assigning the result to an int which is 32-bit, causing integer wraparound :-( So this code will likely crash & burn on any file > 2 GB in length Thou shalt always uses size_t when dealing with file sizes !
Created attachment 951726 [details] Fix int overflow in file I/O
FYI I sent the patch & bug report upstream too https://code.google.com/p/rawtherapee/issues/detail?id=2551
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.