review-request: Fix invalid data-pointer in the msword-filter (2)

Sebastian Sauer mail at dipe.org
Thu Jun 9 16:21:43 BST 2011


On Wednesday 08 June 2011 22:37:13 Sebastian Sauer wrote:
> Please find attached a patch that fixes bug 275204. The reason for the bug
> was that we where ending with random values cause what could work but
> sometimes didn't. The values where random cause we dealed with mem past
> the allocated number of U8-bytes.

Seems the previous patch wasn't correct / wasn't enough to fix the problem. 
Please find attached an updated patch that tries to make sure that we never 
end outside of the UPX-boundaries by not trusting cbUPX to have the correct 
value and limit it additionally to the U8* data-size the UPX is in.

In the last 30 minutes of loading the doc attached to bug 275204 I was at 
least not able to produce the problem any longer with the attached patch. But 
then since it's a rather random problem...

Even after studying the msdoc-binary specs for a longer time I am still not 
sure why that is so. Either the producer of that doc attached to bug 275204 
just produced garbage or we are missing something. Following sentence from the 
specs seems to match;

[quote]
Each UPX stored in a file is not a complete UPX, rather it is a UPX
with all trailing zero bytes lopped off, and preceded by a ushort
length field.  So it is stored like:
                                 Field     Size Comment
                                 cbUPX     2 bytes   size of the
                                 following UPX structure
                                 UPX  (cbUPX)   Nonzero prefix of a
                                 UPX structure
Each UPX begins on an even-byte offset within the STD, even if the
length of the previous UPX (cbUPX) was odd.
[/quote]

So,
1) can "with all trailing zero bytes lopped" maybe mean that cbUPX does not 
really define that exact size of bytes in the stream but the size of the 
produced UPX structure which can be different thanks to the trailing zero 
bytes lopped or
2) are we probably not handling the even-byte case correct and therefore earn 
garbage sometimes?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FixInvalidDataPointer-2.patch
Type: text/x-patch
Size: 2706 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20110609/5f93b71e/attachment.bin>


More information about the calligra-devel mailing list