The test bmp size is 16x1073741836, bpp is 32.
This cause the image.NewNRGBA(image.Rect(0, 0, c.Width, c.Height)) panic.
I think this is not a bug.

My understanding is that BMP is not compressed format. So decoding must try to allocate 16x1073741836x4 only if input size is larger than that. In this case input is few bytes, so an attempt to allocate 64GB of memory does look like a bug.
FWIW, encoding/gob has such logic that detects when declared data size is larger than input.
Ideally we have such logic for compressed image formats as well. But it is not directly possible. Probably we can introduce MaxMem option for decoding of compressed formats, i.e. "decode this blob using no more than 100MB of memory".

@minux x/image/bmp does not supports any compression.

@dvyukov, use Go 1.5 milestone for bugs in released code. Subrepos are not released. The code in x/image/bmp and Go 1.5 are completely unrelated. The milestone for subrepos is Unreleased.

BMP is not a compressed format, but the structure of the file format is first header, then payload. The image dimensions are in the header, and the decoder allocates a pixel buffer after the header is processed but before the payload is processed, because processing the payload involves writing the pixels to somewhere: the pixel buffer.

Decode takes an io.Reader, not an io.ReadSeeker, so at the time it allocates the pixel buffer, it cannot know whether or not there's 'enough input' remaining. Conversely, we may be decoding an image downloaded from a socket, where we cannot know how much input is remaining. So I think this is all WAI.

For decoding images in general, with compression, knowing the total file size doesn't necessarily mean that you know whether or not there's enough pixel data. LZW-style length-difference or RLE encoding means that very large uncompressed data can compress very, very well.

That the various image libraries should reject an 16x1073741836 early, checking some sort of MaxMem option before allocating a buffer, is issue #5050.