[tanjiroK-coder]

WebPDecoder never overrode set_limits, so Limits::max_alloc was never handed to image_webp::WebPDecoder::set_memory_limit and the backend kept its default of usize::MAX. image-webp indexes chunks by seeking past their declared RIFF length without comparing it to the stream length, and read_chunk then sizes the ICCP/EXIF/XMP buffer with vec![0; len] before reading. A 64-byte extended WebP whose EXIF chunk declares 0xFFFFFFF0 bytes is enough: ImageReader::decode reads InHeader metadata eagerly, so with max_alloc at 1 MiB a counting allocator still saw a single 4294967280-byte request before the read hit EOF. That ignores the allocation cap callers set for untrusted input, and on 32-bit targets or hosts without overcommit an allocation that size aborts the process instead of returning an error. I found it while checking which decoders actually pass max_alloc to their backend. PNG and TIFF do, WebP did not. The new set_limits keeps the default support and dimension checks and forwards the cap, and MemoryLimitExceeded now maps to ImageError::Limits instead of a generic decoding error. The added unit test uses that crafted file, fails on main with an IoError, and passes with the patch. cargo test, cargo fmt --check and clippy with -D warnings are clean.