Pillow is a Python imaging library. Prior to 13.0.0, the TarIO initializer in src/PIL/TarIO.py accepts a negative octal member size and computes a backward seek that returns to the same 512-byte header. When the requested member name does not match, the parser repeatedly reads that header, consumes a full CPU core, and never returns. TarIO is reached only when an application directly uses PIL.TarIO.TarIO rather than the default Image.open() path. This issue is fixed in version 13.0.0.

Affected: PyPI: Pillow

### Summary `TarIO.__init__` does not check that a tar header's size field is positive. A crafted header with a negative size makes it seek backward onto itself. This causes an infinite loop that uses 100% CPU and never returns.

### Details `TarIO.__init__` reads 512-byte tar headers one at a time, looking for a member with a given name. For each header it reads the size field and skips ahead to the next header:

```python size = int(s[124:135], 8) ... self.fh.seek((size + 511) & (~511), io.SEEK_CUR) ``` There is no check that size is zero or more. A tar header can set this field to a negative octal value. For size = -512, the seek offset comes out to exactly -512, which cancels the 512 bytes the loop had just read. The file position goes right back to where this loop step started.

The loop only stops on end of file or when a header name starts with a null byte. Neither happens, since the same header keeps showing up again. The loop never ends on its own.

### Steps to reproduce

This uses Tests/images/hopper.tar, a normal file already in the Pillow test suite. It only changes the size field of the first header.

```python from PIL import TarIO

with open("Tests/images/hopper.tar", "rb") as f: data = bytearray(f.read())

# Set the size field (bytes 124 to 135) to a negative octal value. # Octal 1000 is 512, so this is size = -512. data[124:135] = b" -00001000"

with open("poisoned.tar", "wb") as f: f.write(data)

# "does-not-exist" does not match the header name,…