Am Montag, 12. November 2018, 13:49:26 schrieb Alexandre Julliard:
Henri Verbeet hverbeet@gmail.com writes:
On Mon, 12 Nov 2018 at 14:28, Huw Davies huw@codeweavers.com wrote:
If table->len (which itself is a DWORD) gets bigger than 0xfffffffflu - 3 it will overflow in (table->len + 3) and HeapAlloc does not allocate as much memory as expected.
I don't think that's worth covering. I've sent in a cleaner version.
I'm inclined to side somewhat with Wolfgang here. I.e., fonts are essentially untrusted data, and it seems plausible enough that someone may set unreasonable values on purpose.
It seems to me that this should be caught by the lower layers, ideally in FreeType or else in gdi32.
A table lenght of 0xffffffff could be valid (at least in theory). Though the length of a table must be a multiple of 4 bytes including padding, the padding should not ne recorded:
"The length of all tables should be recorded in the table record with their actual length (not their padded length)."
https://docs.microsoft.com/de-de/typography/opentype/spec/otff
On the other hand the example code given there for calculating the checksum would not work with 0xffffffff.
So a very large font with > 4G could contain such a table and freetype could accept it?
But probably wineps has other parts where it does not check for overflows or malicious data, i.e. when accessing the glyph table.
Regards,