Repository navigation
Conversation
|
Thanks very much. However, it turns out that we've been preparing a similar change internally. I've created #10105. If you think that we've missed anything in our version of this, please let us know. |
|
Had a look through #10105. It covers the same four plugins (DCX, MPO, MIC, PSD) and centralising the guard in |
|
For the record, when I said "we've been preparing a similar change internally", that was code for "this is a security problem that's already been reported to us". Please consider https://pillow.readthedocs.io/en/stable/handbook/security.html#security-reporting moving forward. |
ImageFile.load_prepare()only allocates a new backing image whenself._im is None, so a multi-frame plugin that re-opens onseek()reuses the previous frame's buffer. If the next frame keeps the same dimensions but widens the mode (anLframe followed byRGB, say), the tile still passes thesetimage()bounds check, and the unpacker writespixelsizebytes per pixel into a buffer sized for the narrower mode, overrunning each row.With libgmalloc guard pages this faults deterministically in the decode loop:
TiffImageFile.seek()already drops the buffer when its size or mode changes. DCX, MPO and MIC re-run another plugin's_open()onseek(), and PSD swaps the layer mode, none of them clearing_im.Changes proposed in this pull request:
TiffImageFile.seektoDcxImageFile.seek,MpoImageFile.seek,MicImageFile.seekandPsdImageFile.seek, so the backing image is reused only when its geometry still matches.