GeezerVison

liblzma allocates the full LZMA dictionary up front when a decompressor is created, and the dictionary size comes from the stream header. An untrusted stream can declare a multi-gigabyte dictionary (up to 4 GiB) and force that allocation from a handful of bytes — a memory denial of service.

Both crash paths were reported by OSS-Fuzz (python3-libraries, public):

• fuzzer-zipfile OOM: a 1088-byte zip whose LZMA member declares a ~2 GiB dictionary → https://issues.oss-fuzz.com/issues/495472861
• fuzzer-tarfile OOM: a 13-byte input whose first byte is a valid LZMA-alone properties byte with a ~4 GiB dictionary → https://issues.oss-fuzz.com/issues/482161128

Directly reachable too: lzma.decompress() / LZMADecompressor(FORMAT_AUTO) on untrusted bytes, and LZMADecompressor(FORMAT_RAW, filters=[{"dict_size": ...}]).

Changes

1. parse_filter_spec_lzma() rejects dict_size above liblzma's own maximum (LZMA_DICT_SIZE_MAX, 1.5 GiB) with LZMAError — covers raw LZMA1/LZMA2 filter chains, including zipfile's LZMA members (the dictionary is parsed from the 5-byte properties header before any data is decompressed).
2. LZMADecompressor defaults memlimit to LZMA_DICT_SIZE_MAX instead of UINT64_MAX — bounds the FORMAT_AUTO/FORMAT_ALONE/FORMAT_XZ paths where the header is parsed inside liblzma (tarfile compression detection, lzma.decompress(), LZMAFile).

An explicit memlimit can still be passed to raise or lower the bound.

Compatibility: liblzma presets cap at 64 MiB dictionaries; 1.5 GiB is liblzma's own maximum supported dictionary size, so no legitimate stream is affected.

Tests: new regression tests in test_lzma.py, test_zipfile (crafted bomb zip → LZMAError), and test_tarfile (13-byte fake-LZMA input → ReadError). test_lzma test_zipfile test_tarfile all pass (1,487 tests).

Companion fuzzer-harness change: https://github.com/python/library-fuzzers/pull/… (zipfile fuzzer now tolerates lzma.LZMAError).

• Issue: lzma: unbounded dictionary-size allocation is a memory DoS (zipfile, tarfile, lzma.decompress) #155649