When decoding a tiled TIFF with fax compression (T4/T6/MH), DecodeTilesChunky allocates each tile buffer from TileWidth (ceil(TileWidth*bpp/8)*TileLength bytes) but constructs the fax decompressor with frame.Width: TiffDecompressorsFactory ignores the isTiled/tileWidth/tileHeight parameters entirely. The T4/T6/MH decompressors treat the full image width as the scanline length and advance (and really write, via read-modify-write bit ops) frame.Width bits per row, with no bounds check against the tile buffer. The very first tile therefore writes …
The TIFF CCITT Group 4 (T6) encoder writes beyond its logical compressed-data buffer when encoding a 1-bit image. A valid 1×1 Group 4 TIFF decoded and re-encoded with the default TiffEncoder terminates the process with an unhandled exception.
ImageSharp's TIFF CCITT Group 3 (T4) encoder can write beyond its allocated compressed-data buffer when encoding narrow 1-bit images. The unchecked writes can corrupt process memory and terminate the process. This report concerns only the T4 CcittGroup3Fax encoder path. It replaces the prior, unrelated ICC content.
When ICC conversion is enabled, a malformed embedded ICC LUT16 profile with more than four output channels can corrupt memory during ImageSharp color conversion. The ICC parser accepts up to 15 CLUT output channels, while the conversion implementation stores intermediate values in Vector4.
A malformed embedded ICC profile can make ImageSharp allocate memory from attacker-controlled CLUT channel and grid dimensions before verifying that the declared CLUT values are present. In published v1 through v3 packages, the public lazy ICC parser allocates approximately 115 MB from the 200-byte test profile before rejecting the truncated tag. In published v4 packages, decoding with ICC conversion enabled requests an 860,934,420-byte managed float array from the same profile.
SixLabors.ImageSharp can terminate a process when an application decodes an attacker-supplied 32-bit floating-point TIFF as Image<HalfVector4> and applies HistogramEqualization(). An IEEE positive-infinity TIFF sample reaches a non-finite or otherwise out-of-range HalfVector4 component, depending on the release. The histogram equalization path derives a luminance-based histogram index without validating that result, reaching an unsafe out-of-range access. This report covers HistogramEqualization only. It does not claim Adaptive Histogram Equalization or AutoLevel behavior.
A crafted ZIP-compressed OpenEXR image can return stale memory from a prior ImageSharp operation as decoded pixels. The ZIP decoder accepts a non-empty inflate result shorter than the EXR block's required size, then the EXR decoder reads the full expected block. This is a process-local, cross-operation information-disclosure defect. It is relevant when an application uses the shared Configuration.Default allocator for separate image operations and exposes pixels or output derived from …
SixLabors.ImageSharp 4.1.1 can spend an attacker-controlled duration decoding a small malformed BigTIFF. The BigTIFF IFD entry-count field is 64-bit. The reader iterates once per declared entry, but when fewer than 20 bytes remain for an entry, the entry read returns without advancing. A 24-byte input can therefore run billions of iterations without consuming input. One decoder invocation occupied one executing thread for more than five seconds in the tested environment. …