Affected: Homebrew: aider
### Summary
On `main`, even with the guard in #9725, it's possible to have these decoders read 1 to 3 bytes past the end of the passed buffer with a suitable width/height.
### Details
`ImagingRawDecode` and the `P;2L` / `P;4L` unpackers disagree about how many bytes a line of data occupies.
The raw decoder derives the line size from the bits per pixel
```c state->bytes = (state->xsize * state->bits + 7) / 8; ```
and uses it both for the bounds check and to advance to the next line. For `P;2L` and `P;4L`, `bits` is 2 and 4 respectively.
But these two rawmodes are not packed pixels but 2 or 4 *bit planes*, each padded to a whole number of bytes. `unpackP2L` computes `s = (pixels + 7) / 8` and reads plane *k* at offset `k * s`, and `unpackP4L` does the same across four planes. Their real footprint is therefore `planes * ((xsize + 7) / 8)`.
For some widths, padding each plane separately makes this footprint larger than `state->bytes`. For example, at width 1, the decoder accounts for one byte, while the unpackers read two or four bytes. The decoder accepts data that is too short for the last line and on the other hand advances to subsequent lines by less than a line, so every line after the first is also read from the wrong offset.
#9725's check is misshapen for this:
* It can reject data of the right length: 8x1 `P;2L` image is 2 bytes but is not accepted. * It still accepts buffers shorter than the unpackers require for a given image shape. * It measures the length w…
Pillow is a Python imaging library. Prior to 13.0.0, Pillow's P;2L and P;4L raw decoders can read past the end of an input buffer. ImagingRawDecode calculates a packed-pixel row size, while the unpackers read separately padded bit planes. A caller can supply a buffer and image dimensions whose accepted size is smaller than the unpacker's actual footprint. This can disclose up to three adjacent heap bytes in output pixels or crash the process. This issue is fixed in version 13.0.0.
Affected: PyPI: Pillow
### Summary
On `main`, even with the guard in #9725, it's possible to have these decoders read 1 to 3 bytes past the end of the passed buffer with a suitable width/height.
### Details
`ImagingRawDecode` and the `P;2L` / `P;4L` unpackers disagree about how many bytes a line of data occupies.
The raw decoder derives the line size from the bits per pixel
```c state->bytes = (state->xsize * state->bits + 7) / 8; ```
and uses it both for the bounds check and to advance to the next line. For `P;2L` and `P;4L`, `bits` is 2 and 4 respectively.
But these two rawmodes are not packed pixels but 2 or 4 *bit planes*, each padded to a whole number of bytes. `unpackP2L` computes `s = (pixels + 7) / 8` and reads plane *k* at offset `k * s`, and `unpackP4L` does the same across four planes. Their real footprint is therefore `planes * ((xsize + 7) / 8)`.
For some widths, padding each plane separately makes this footprint larger than `state->bytes`. For example, at width 1, the decoder accounts for one byte, while the unpackers read two or four bytes. The decoder accepts data that is too short for the last line and on the other hand advances to subsequent lines by less than a line, so every line after the first is also read from the wrong offset.
#9725's check is misshapen for this:
* It can reject data of the right length: 8x1 `P;2L` image is 2 bytes but is not accepted. * It still accepts buffers shorter than the unpackers require for a given image shape. * It measures the length w…
python313-Pillow-13.0.0-1.1 on GA media
Affected: Ubuntu:Pro:14.04:LTS: pillow, Ubuntu:Pro:16.04:LTS: pillow, Ubuntu:Pro:18.04:LTS: pillow, Ubuntu:Pro:20.04:LTS: pillow, Ubuntu:Pro:20.04:LTS: pillow-python2, Ubuntu:22.04:LTS: pillow, Ubuntu:24.04:LTS: pillow, Ubuntu:26.10: pillow, Ubuntu:26.04:LTS: pillow
(Pillow is a Python imaging library. Prior to 13.0.0, Pillow's P;2L and ...)