x/image/tiff: OOM from malicious IFD offset

[ZephrFish]

A crafted 8-byte TIFF file with IFD offset 0xFFFFFFFF causes
buffer.fill() to allocate ~4GB of memory when decoding via
io.Reader (non-ReaderAt path), leading to an out-of-memory
crash in any Go application that calls Decode or DecodeConfig
on untrusted input.

Read the data, and allocate the buffer, in chunks,
to limit memory allocation to the size of the input file.

Fix: golang/image#25
References: https://issuetracker.google.com/issues/494365189

[gopherbot]

Change https://go.dev/cl/757660 mentions this issue: tiff: cap buffer growth to prevent OOM from malicious IFD offset

[gabyhelp]

Related Issues

• x/image/tiff: over allocation in DecodeConfig (CVE-2022-41727) #58003 (closed)
• x/image/tiff: lack of limits on compressed tile data [CVE-2023-29408] #61582 (closed)
• x/image/tiff: excessive CPU consumption from no-op loop iterations [CVE-2023-29407] #61581 (closed)
• x/image/tiff: corrupt or malicious paletted images parse successfully and later panic in (*Palleted).At #67624 (closed)
• x/image/tiff: slice bounds out of range #10395 (closed)
• x/image/tiff: index out of range #10597 (closed)
• x/image/tiff: slice bounds out of range #10596 (closed)
• x/image/tiff: integer divide by zero #10393 (closed)

Related Discussions

• [security] Vulnerability in golang.org/x/image/tiff
• [security] golang.org/x/image/tiff fix pre-announcement

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[jub0bs]

@ZephrFish Shouldn't this have been filed as a private report to the security team?

[neild]

We've assigned this CVE-2026-33809. This is de-facto PUBLIC track, since it's public now.