Bug 70483 - FILEOPEN: Aborts when opening malformed DOC files
Summary: FILEOPEN: Aborts when opening malformed DOC files
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.2.3 release
Hardware: Other All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: BSA target:4.2.0
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-15 08:55 UTC by Alexandru Blanda
Modified: 2013-10-29 11:49 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
files that can be used to reproduce the crash (55.18 KB, application/zip)
2013-10-15 08:55 UTC, Alexandru Blanda
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandru Blanda 2013-10-15 08:55:27 UTC
Created attachment 87657 [details]
files that can be used to reproduce the crash

Problem description: 

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

Program received signal SIGABRT, Aborted.
0x0000003001835329 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);

Attached you can find an archive that contains several sample files that can be used to reproduce the problem.
The files were generated by fuzzing valid files, in order to check for problems when libreoffice handles malformed input.
The bug was found while testing Libreoffice version 4.0.1.2, but it is persistent in version 4.1.2.3

Steps to reproduce:
1. Open libreoffice with gdb attached
2. Open the files from the attached archive

A gdb backtrace example of opening one of the files can be found here:
https://docs.google.com/file/d/0Bw_O6opVYHaaSzFTV2gwMWtxR2M/edit?usp=sharing

              
Operating System: Ubuntu
Version: 4.1.2.3 rc
Comment 1 Miklos Vajna 2013-10-16 18:37:56 UTC
Backtrace for sf_6ea3a0f683768c3ccc999a674acfd1ac-89918.doc:

#1  0x00007fffef39e4be in __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<rtl::Reference<StgPage>*, std::__cxx1998::vector<rtl::Reference<StgPage>, std::allocator<rtl::Reference<StgPage> > > >, std::__debug::vector<rtl::Reference<StgPage>, std::allocator<rtl::Reference<StgPage> > > >::_M_is_end (this=0x7fffffff7fe0) at /usr/include/c++/4.7/debug/safe_iterator.h:463
#2  0x00007fffef39cfbb in __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<rtl::Reference<StgPage>*, std::__cxx1998::vector<rtl::Reference<StgPage>, std::allocator<rtl::Reference<StgPage> > > >, std::__debug::vector<rtl::Reference<StgPage>, std::allocator<rtl::Reference<StgPage> > > >::_M_dereferenceable (this=0x7fffffff7fe0)
    at /usr/include/c++/4.7/debug/safe_iterator.h:420
#3  0x00007fffef39bec3 in __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<rtl::Reference<StgPage>*, std::__cxx1998::vector<rtl::Reference<StgPage>, std::allocator<rtl::Reference<StgPage> > > >, std::__debug::vector<rtl::Reference<StgPage>, std::allocator<rtl::Reference<StgPage> > > >::operator-> (this=0x7fffffff7fe0) at /usr/include/c++/4.7/debug/safe_iterator.h:276
#4  0x00007fffef39a347 in StgCache::Find (this=0x1612290, nPage=321) at /master/sot/source/sdstor/stgcache.cxx:161
#5  0x00007fffef39a51f in StgCache::Get (this=0x1612290, nPage=321, bForce=true) at /master/sot/source/sdstor/stgcache.cxx:173
#6  0x00007fffef3ad017 in StgFAT::GetPhysPage (this=0x15feee0, nByteOff=1304) at /master/sot/source/sdstor/stgstrms.cxx:62
#7  0x00007fffef3ad0a9 in StgFAT::GetNextPage (this=0x15feee0, nPg=326) at /master/sot/source/sdstor/stgstrms.cxx:73
#8  0x00007fffef3adf72 in StgStrm::scanBuildPageChainCache (this=0x161de40, pOptionalCalcSize=0x161de64) at /master/sot/source/sdstor/stgstrms.cxx:349
#9  0x00007fffef3afd1f in StgDataStrm::Init (this=0x161de40, nBgn=322, nLen=-1) at /master/sot/source/sdstor/stgstrms.cxx:824
#10 0x00007fffef3afb66 in StgDataStrm::StgDataStrm (this=0x161de40, r=..., nBgn=322, nLen=-1) at /master/sot/source/sdstor/stgstrms.cxx:799
#11 0x00007fffef3a7db6 in StgDirStrm::StgDirStrm (this=0x161de40, r=...) at /master/sot/source/sdstor/stgdir.cxx:780
#12 0x00007fffef3ab0bf in StgIo::SetupStreams (this=0x1612290) at /master/sot/source/sdstor/stgio.cxx:91
#13 0x00007fffef3aaeca in StgIo::Load (this=0x1612290) at /master/sot/source/sdstor/stgio.cxx:59
#14 0x00007fffef3959ad in Storage::Init (this=0x156b400, bCreate=false) at /master/sot/source/sdstor/stg.cxx:482
#15 0x00007fffef395594 in Storage::Storage (this=0x156b400, r=..., bDirect=false) at /master/sot/source/sdstor/stg.cxx:411
#16 0x00007fffef3b6b11 in SotStorage::SotStorage (this=0x1606a40, pStm=0x15fedb0, bDelete=false, __in_chrg=<optimized out>, __vtt_parm=<optimized out>)
    at /master/sot/source/sdstor/storage.cxx:535
#17 0x00007fffd8be6e00 in SwIoSystem::IsFileFilter (rMedium=..., rFmtName="CWW8") at /master/sw/source/filter/basflt/iodetect.cxx:213
#18 0x00007fffd8be9ca9 in SwFilterDetect::DetectFilter (rMedium=..., ppFilter=0x7fffffff9778) at /master/sw/source/ui/uno/swdet2.cxx:55
#19 0x00007fffd8beb010 in SwFilterDetect::detect (this=0x15fd380, lDescriptor=uno::Sequence of length 9 = {...}) at /master/sw/source/ui/uno/swdetect.cxx:332
#20 0x00007fffda69e127 in filter::config::TypeDetection::impl_askDetectService (this=0x158dbe0, sDetectService="com.sun.star.text.FormatDetector", rDescriptor=...)
    at /master/filter/source/config/cache/typedetection.cxx:1039

Looks like WW8 type detection goes mad and at the end eats all the available memory.
Comment 2 Michael Meeks 2013-10-16 19:32:34 UTC
I just ported and cleaned up this commit:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=dfa1afd0e8b7ae9c706c4a3171a04752e24230b0

Which would fix this issue. Anyone wanting to review / cherry-pick it to -4-1 & 4-0- it would be appreciated :-)
Comment 3 Commit Notification 2013-10-29 11:49:52 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=203d3e63762bb269f9a111279d9e800f20adaf33

Related: fdo#70483 add regression test



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.