Signed-off-by: Torge Matthies openglfreak@googlemail.com --- dlls/windowscodecs/tests/pngformat.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
diff --git a/dlls/windowscodecs/tests/pngformat.c b/dlls/windowscodecs/tests/pngformat.c index 8c33d3b9645..79d8a6fbe7f 100644 --- a/dlls/windowscodecs/tests/pngformat.c +++ b/dlls/windowscodecs/tests/pngformat.c @@ -922,6 +922,25 @@ todo_wine_if(td[i].todo) #undef PNG_COLOR_TYPE_GRAY_ALPHA #undef PNG_COLOR_TYPE_RGB_ALPHA
+/* 1 bpp 1x1 pixel PNG image with 8 MiB comment */ +static const char png_8M_tEXt[] = { + 0x89,'P','N','G',0x0d,0x0a,0x1a,0x0a, + 0x00,0x00,0x00,0x0d,'I','H','D','R',0x00,0x00,0x00,0x01,0x00,0x00,0x00,0x01,0x01,0x00,0x00,0x00,0x00,0x37,0x6e,0xf9,0x24, + 0x00,0x80,0x00,0x08,'t','E','X','t','C','o','m','m','e','n','t',0x00,[0x800030]=0x00,0x1e,0x13,0xe2,0xc7, + 0x00,0x00,0x00,0x0c,'I','D','A','T',0x78,0x9c,0x63,0x68,0x00,0x00,0x00,0x82,0x00,0x81,0x77,0xcd,0x72,0xb6, + 0x00,0x00,0x00,0x00,'I','E','N','D',0xae,0x42,0x60,0x82 +}; + +static void test_chunk_size(void) +{ + HRESULT hr; + IWICBitmapDecoder *decoder; + + hr = create_decoder(png_8M_tEXt, sizeof(png_8M_tEXt), &decoder); + todo_wine ok(hr == S_OK, "Failed to load PNG image data %#x\n", hr); + if (hr != S_OK) return; +} + START_TEST(pngformat) { HRESULT hr; @@ -935,6 +954,7 @@ START_TEST(pngformat) test_color_contexts(); test_png_palette(); test_color_formats(); + test_chunk_size();
IWICImagingFactory_Release(factory); CoUninitialize();
Reading a PNG file with libpng with a chunk bigger than the 8 MiB default chunk size limit set by libpng results in a libpng error, e.g. "iTXt: chunk data is too large" for a too big iTXt chunk.
Fix this by disabling the chunk size limit.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52147 Signed-off-by: Torge Matthies openglfreak@googlemail.com --- dlls/windowscodecs/libpng.c | 1 + dlls/windowscodecs/tests/pngformat.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/dlls/windowscodecs/libpng.c b/dlls/windowscodecs/libpng.c index 27a735550f3..8e876b23efe 100644 --- a/dlls/windowscodecs/libpng.c +++ b/dlls/windowscodecs/libpng.c @@ -107,6 +107,7 @@ static HRESULT CDECL png_decoder_initialize(struct decoder *iface, IStream *stre goto end; } png_set_crc_action(png_ptr, PNG_CRC_QUIET_USE, PNG_CRC_QUIET_USE); + png_set_chunk_malloc_max(png_ptr, 0);
/* seek to the start of the stream */ hr = stream_seek(stream, 0, STREAM_SEEK_SET, NULL); diff --git a/dlls/windowscodecs/tests/pngformat.c b/dlls/windowscodecs/tests/pngformat.c index 79d8a6fbe7f..8545b9d3359 100644 --- a/dlls/windowscodecs/tests/pngformat.c +++ b/dlls/windowscodecs/tests/pngformat.c @@ -937,7 +937,7 @@ static void test_chunk_size(void) IWICBitmapDecoder *decoder;
hr = create_decoder(png_8M_tEXt, sizeof(png_8M_tEXt), &decoder); - todo_wine ok(hr == S_OK, "Failed to load PNG image data %#x\n", hr); + ok(hr == S_OK, "Failed to load PNG image data %#x\n", hr); if (hr != S_OK) return; }
This leaks the decoder.
Also, I'm not familiar with this syntax + 0x00,0x80,0x00,0x08,'t','E','X','t','C','o','m','m','e','n','t',0x00,[0x800030]=0x00,0x1e,0x13,0xe2,0xc7, Is this going to make the binary larger by filling the gap with zeros, or is the compiler smart enough to leave those pages out of the binary? If it's going to add 8 MiB to the binary, we might want to do that in code instead.
It does add 8 MiB to the binary. Not sure if that's acceptable.
I'd be willing to accept the fix without tests if that's a problem.
I can do it in code; I'm going to split png_8M_tEXt into a _start and an _end and copy them both into an array at runtime. The [0x800030]= is C99 syntax, which just skips to that point in the array.
On Fri, 3 Dec 2021 at 18:48, Esme Povirk (she/they) esme@codeweavers.com wrote:
It does add 8 MiB to the binary. Not sure if that's acceptable.
I'd be willing to accept the fix without tests if that's a problem.
-
Esme Povirk (she/they) -
Torge Matthies