GHSA-24rc-8hj2-v98c: Medium severity pip/pillow vulnerability

Summary BmpRleDecoder can be forced to allocate gigabytes of memory from a kilobyte-sized crafted BMP file via unbounded growth in the delta escape and absolute mode branches.

Affected versions All versions up to and including current HEAD (v13.0.0.dev0, commit e7a7ea84)

Root cause BmpRleDecoder.decode() (BmpImagePlugin.py:327-395) builds a Python bytearray data with destlength = xsizeysize, looping while len(data) < destlength. The loop condition is only checked at the TOP; individual branches append attacker-controlled amounts UNBOUNDED by destlength:

- delta escape (line 370): data += b"\x00" (right + up self.state.xsize) with right,up in 0..255 -> up to ~255xsize bytes in ONE iteration. - absolute mode (line 385): data += bytesread (up to 255).

Because a single delta can push len(data) to ~256 (row size), a tiny RLE stream combined with a large-but-legal xsize (xsizeysize just under MAXIMAGEPIXELS, ~89M) yields a multi-GB data bytearray (then copied again by bytes(data) and setasraw). No heap OOB (bytearray/setasraw are bounds-safe), but a severe memory-amplification DoS: the attacker file stays tiny.

Reproduction Python 3.13, Pillow HEAD e7a7ea84

Attached: pillowpocbmprledos.py

A 1084-byte BMP (BIRLE8, width=3,000,000, height=1 -> 3M px, passes bomb check) with one delta escape (00 02 00 150) produces ~429 MB data; measured peak RSS 911 MB. Scaling width toward the bomb limit and up=255 produces tens of GB from a ~1 KB file.

Suggested fix Cap growth at destlength in the delta and absolute branches, e.g. clamp the delta fill to (destlength - len(data)) and stop appending once len(data) >= destlength; reject deltas that would move the cursor beyond the image, matching the existing per-row clamp at line 341-343.

Credit: Yazan Balawneh - CyStack Security Team (GitHub: sonicnew)

pillowpocbmprledos.py