<p><pre><code>    Some applications might read the bit depth from the IHDR chunk and allocate
    memory for a 2^N entry palette, while libpng can return a palette with up
    to 256 entries even when the bit depth is less than 8.
</code></pre>
On initial review, this will require assumptions in the client application to be exploitable. I haven&#x27;t found a place where libpng itself causes the overrun. It is just an enabler by returning a smaller value for bit_depth than num_palette. If the application double-checks the result from png_get_PLTE or uses PNG_MAX_PALETTE_LENGTH instead of 1&lt;&lt;bit_depth, it won&#x27;t have a problem except wasting memory.<p>Unfortunately RFC 2083 contains the requirement that a compliant PLTE will not be larger than the bit depth. So I&#x27;m sure many applications that trusted libpng to do the validation will be exploitable. I consider this a caution against promising too much in the spec, as well as not overly relying on an implementation to exactly follow the spec. Remember the robustness principle: be conservative in what you send, be liberal in what you accept.