2009.04.26 17:22 "[Tiff] Packbits worst case encoded length", by Simon Berger

2009.05.05 18:32 "Re: [Tiff] Packbits worst case encoded length", by Bob Friesenhahn

wrong that the malloc library can not detect. Guard pages are only somewhat useful since they only cover the case where there is a linear overwrite past the end of the allocated buffer.

Sure, but this is a **very** common and dangerous case.

Is it more dangerous than the other cases? What would cause one case to be more dangerous than another?

Guard pages are pages of memory that you can't read or write. There is no "original guard content" to preserve. Any attempt to read or write to a guard page will cause an immediate crash.

Ahhh, I see. This wastes a whole MMU page (4K, 8K, 16K, or ???) per memory allocation. It also needs to start on a MMU page boundary, which may be far beyond the user-requested allocation. If the user requests 128 bytes, then that leaves a long region which is unchecked and the underlying allocation really needs to be at least a page long. In order to be safe, there needs to be protection against underflow, so the page below needs to be a guard page as well. The end result is that there is huge waste of memory if the user allocations are small.

It seems that the strategy taken can be controlled by which malloc library is linked to at library link time, program link time, or preloaded via an OS specific means.

Sure, though decompression code isn't dealing with those. Decompression code is a common source of trouble.

No doubt.

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/