In versions of Python from 3.4-3.10, the Python core plistlib library supports Apple's binary plist format. When given malformed input, the implementation can be forced to create an argument to struct.unpack() which consumes all available CPU and memory until a MemError is thrown as it builds the 'format' argument to unpack().

This can be seen with the following malformed example binary plist input:

```
$ xxd binary_plist_dos.bplist
00000000: 6270 6c69 7374 3030 d101 0255 614c 6973  bplist00...UaLis
00000010: 74a5 0304 0506 0000 00df 4251 4351 44a3  t.........BQCQD.
00000020: 0809 0a10 0110 0210 0308 0b11 1719 1b1d  ................
00000030: 0000 0101 0000 0000 0000 000b 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0029            ...........)

```
The error is reached in the following lines of plistlib.py:
(https://github.com/python/cpython/blob/e9959c71185d0850c84e3aba0301fbc238f194a9/Lib/plistlib.py#L485)

```
    def _read_ints(self, n, size):
        data = self._fp.read(size * n)
        if size in _BINARY_FORMAT:
            return struct.unpack('>' + _BINARY_FORMAT[size] * n, data)
```
When the malicious example above is opened by plistlib, it results in 'n' being controlled by the input and it can be forced to be very large. Plistlib attempts to build a string which is as long as 'n', consuming excessive resources.

Apple's built in utilities for handling plist files detects this same file as malformed and will not process it.