Am Freitag, 28. Januar 2011, 11:58:17 schrieb Karsten König:
> the constructor of oleinputstream has troubles validating the filesize,
> especially when KMetaFileInfo limits the filesize to 64k.
> kde bugreport: https://bugs.kde.org/attachment.cgi?bugid=251701
> Until now the code tries guessing the maximum blockid and turns this into
> an expected filesize, I replaced that guessing with the calculation of a
> minimum and maximum size, assuming the that the last block allocation
> table doesn't only point at free blocks. So there still is a possible
> error window of 64k at the end of the file, but it should be more robust
> then the current state, I am off for the weekend but I'll add a section to
> read the last part of the bat and thus get the real filesi> ze and check if
> this fits with the size we read from the file.
Ok, I added this, it reads the last block for the block allocation table and
checks in reverse order for the first non-free block, this has to be included
in the filesize.
> Is this patch acceptable or am I overlooking something important?
Please somebody check this stuff, it is crashing KDE application from 4.6 that
use KFileMetaInfo on a big ole compound document format file, this stuff gets
shipped to users who will always see a crash thanks to oleinputstream
constructor lacking proper input checking.
Here is a fixed link, nobody complained about the old one...