ZLibException escapes the image decoders on a preset-dictionary (FDICT) zlib stream

[nathanpond]

What

A zlib stream whose header sets the FDICT bit (a preset-dictionary stream) makes
System.IO.Compression throw ZLibException, which neither PngDecoder.Inflate nor
TiffDecoder.Inflate catches, and which the ImageReader.TryRead net (#48) does not list. It
escapes Converter and takes the whole conversion down.

Found by the scheduled fuzz job: run
33303663302, job Fuzz image,
exit 77.

Where

• src/n8PDF/Images/PngDecoder.cs:127-145 — catch (InvalidDataException) only.
• src/n8PDF/Images/TiffDecoder.cs:593-607 — the same catch, for Deflate strips (compression 8 / 32946).
• src/n8PDF/Images/ImageReader.cs:58-60 — the TryRead net does not list ZLibException either.

Pdf/PdfFilters.FlateDecode shares the shape but only ever reads bytes we wrote ourselves, so it
is not on the attack surface.

Why it matters

A hostile .docx gets a hard failure of the entire conversion out of two bytes in an image
part. The contract the decoders and TryRead exist to keep is that a malformed picture costs its
own placement and nothing more; here it costs the document. No allocation and no memory unsafety —
hence sev:medium rather than higher — but it is a denial of the conversion from an input that is
trivially cheap to author, and it is exactly the class of hole #48 was opened to close.

The reason it slipped the net is that ZLibException derives from IOException, not from
InvalidDataException, so it is outside every catch clause in the image path.

Reproduction

libFuzzer's minimised unit (a 1x4 8-bit greyscale-alpha PNG whose IDAT begins 78 3f):

Base64: iVBORw0KGgoAAAANSUhEUgAAAAEAAAAECAQAAAgAAAAAAAAADElEQVR4P5xjsmAcAAAARAAB//8dCFMA

ImageReader.TryRead(Convert.FromBase64String("iVBORw0KGgoAAAANSUhEUgAAAAEAAAAECAQAAAgAAAAAAAAADElEQVR4P5xjsmAcAAAARAAB//8dCFMA"));
// System.IO.Compression.ZLibException: The underlying compression routine returned an unexpected error code.
//    at System.IO.Compression.Inflater.Inflate(FlushCode flushCode)
//    at n8PDF.Images.PngDecoder.Inflate(Byte[] compressed, Int64 maxBytes)
//    at n8PDF.Images.PngDecoder.Decode(Byte[] data, Int64 maximumPixels)
//    at n8PDF.Images.ImageReader.Read(Byte[] data, Int64 maximumPixels, Int32 nesting)
//    at n8PDF.Images.ImageReader.TryRead(Byte[] data, Int64 maximumPixels, Int32 nesting)

Reproduced locally on macOS, .NET 10, Release.

FDICT is the whole of the trigger. Feeding ZLibStream a corrupt body under a range of headers,
only the one with bit 5 of FLG set leaves the handled family — zlib returns Z_NEED_DICT and
.NET maps that to ZLibException while mapping everything else to InvalidDataException:

78 9c (no FDICT, corrupt body)  -> InvalidDataException
78 3f (FDICT set)               -> ZLibException          <-- escapes
78 01 (no FDICT)                -> InvalidDataException
08 1d (window 256, FDICT clear) -> InvalidDataException
00 00 (bad CM)                  -> InvalidDataException

Suggested fix

1. Catch ZLibException alongside InvalidDataException in PngDecoder.Inflate and
   TiffDecoder.Inflate, translating it to the ImageFormatException each already raises. A
   preset-dictionary stream is a picture we cannot read, not a fault in the reader — the same
   sentence Images/PngDecoder: InvalidDataException from ZLibStream on a corrupt IDAT escapes uncaught and aborts the conversion #7 and Images/TiffDecoder: malformed Deflate strip data throws InvalidDataException straight out of the decoder #35 already settled for a corrupt one.
2. Add ZLibException to the TryRead net as defence in depth behind those, not instead of them.
3. Tests at the decoder — a PNG and a TIFF whose stream sets FDICT — so the assertion lands
   where the net cannot swallow it, per Images/PngDecoder: IDAT is inflated into an unbounded MemoryStream with no cap against the header's expected size #2/Images/PngDecoder: InvalidDataException from ZLibStream on a corrupt IDAT escapes uncaught and aborts the conversion #7/Images/TiffDecoder: malformed Deflate strip data throws InvalidDataException straight out of the decoder #35.
4. Commit the minimised unit to fuzz/corpus/image/ so replay keeps it.

Acceptance criteria

• PngDecoder.Decode throws ImageFormatException for an FDICT IDAT.
• TiffDecoder.Decode throws ImageFormatException for an FDICT Deflate strip.
• ImageReader.TryRead returns null for the minimised unit above.
• The unit is in the image corpus and FUZZ_TARGET=image ... replay passes.
• Build warning-clean; suite green with qpdf, fontTools and FriBidi on.

[nathanpond]

Plan:

• Catch ZLibException beside InvalidDataException in PngDecoder.Inflate and TiffDecoder.Inflate, translating both to the ImageFormatException each already raises — a preset-dictionary stream is a picture we cannot read, the same sentence Images/PngDecoder: InvalidDataException from ZLibStream on a corrupt IDAT escapes uncaught and aborts the conversion #7 and Images/TiffDecoder: malformed Deflate strip data throws InvalidDataException straight out of the decoder #35 settled for a corrupt one. PdfFilters.FlateDecode is left alone: it only reads bytes we wrote.
• Add ZLibException to the ImageReader.TryRead net, as defence in depth behind the two decoder fixes rather than instead of them, per the standing comment there.
• Tests at the decoder, where the net cannot swallow them: an FDICT case in PngHostileTests and one in the TIFF hostile tests, each asserting ImageFormatException, plus the minimised unit through TryRead asserting null.
• Commit libFuzzer's minimised unit to fuzz/corpus/image/ so replay keeps it, and teach Seed() to write it so a freshly seeded corpus carries it too.
• Files: src/n8PDF/Images/PngDecoder.cs, src/n8PDF/Images/TiffDecoder.cs, src/n8PDF/Images/ImageReader.cs, tests/n8PDF.Tests/PngHostileTests.cs, the TIFF hostile tests, fuzz/Program.cs, fuzz/corpus/image/.

Acceptance criteria are already on the issue; working to those.

[nathanpond]

Done in 296-zlibexception-escapes-the-image-decoders-on-a-preset-dictionary-fdict-zlib-stream @ eec6228, up as #297.

What changed

• PngDecoder.Inflate and TiffDecoder.Inflate now refuse the stream as the ImageFormatException each already raised for a corrupt one; ImageReader.TryRead gains the type behind them as defence in depth.
• The catch says IOException, not ZLibException. ZLibException cannot be named: it is public in System.IO.Compression at runtime but absent from the net10.0 reference assembly, so it does not exist at compile time — error CS0103 on the first attempt. Its public base is what a catch can say. Nothing is lost by the width: the only stream on these paths is a MemoryStream over a byte array already in hand, which performs no I/O, so an IOException there can only be the inflater. The reasoning is written out at each site.
• The TIFF half was not in the crash — it was found by reading and confirmed by a test that fails without the fix. So the finding was wider than the fuzz job showed.

Acceptance criteria

• PngDecoder.Decode throws ImageFormatException for an FDICT IDAT.
• TiffDecoder.Decode throws ImageFormatException for an FDICT Deflate strip.
• ImageReader.TryRead returns null for the minimised unit.
• The unit is in the image corpus and FUZZ_TARGET=image ... replay passes — 6 inputs, 0 escaped, over a freshly seeded corpus. Amended: the criterion said "commit it to fuzz/corpus/image/", which cannot be done — fuzz/corpus/ is gitignored, and CI carries the corpus in the Actions cache, seeding only when empty. fuzz/Program.cs seeds the unit instead, which is the equivalent durable mechanism, and PngHostileTests asserts the same bytes where the suite can see them.
• Build warning-clean; suite green with qpdf, fontTools and FriBidi on — 4833 passed, 0 failed, 6 skipped (the 3-D chart instrument probes). Run on the Mac with Word, so all 143 comparison fixtures ran rather than CI's 97. No golden trace moved: this changes only which exceptions are refused, never output.

All three new tests were confirmed to fail without the fix, each with System.IO.Compression.ZLibException.

PdfFilters.FlateDecode shares the shape and is deliberately untouched — it only ever reads bytes we wrote ourselves.