On Sun, Aug 9, 2026 at 11:27 PM Tom Rini <[email protected]> wrote: > > On Sun, Aug 09, 2026 at 04:23:27AM +0000, Aristo Chen wrote: > > > For a compressed kernel_noload image, bootm_load_os() allocates a > > per-image decompression buffer of ALIGN(image_len * 8, SZ_1M). The 8x > > multiplier is a heuristic: it comfortably covers what zstd and xz > > achieve on real kernels, but any well-compressed payload (say, a big > > run of zeros) can exceed it and fail decompression, and no fixed > > multiplier is safe against arbitrarily compressible input. > > > > Read the real uncompressed size from the compressor header instead. > > Add a small helper image_decomp_get_uncompressed_size() that returns > > the uncompressed size when the format carries one: gzip ISIZE, lzma > > header uncompressed size, lz4 frame Content_Size when the FLG bit is > > set, and zstd Frame_Content_Size. Other formats return -EOPNOTSUPP. > > Bootm uses it to size the buffer to ALIGN(hdr_size, SZ_1M), capped at > > CONFIG_SYS_BOOTM_LEN because the value is attacker-controlled, and > > falls back to the 8x heuristic for formats without a size field > > (bzip2, lzo, xz) or when the header lacks the size (some lzma or lz4 > > streams). > > Have we gotten actual problem reports? This is a good bit of growth for > a problem I'm not sure we're seeing. Thanks.
Thanks for the review! Honest answer: no bug report against the current 8x multiplier has crossed the list. This is preventive rather than reactive, and I should have made that clearer in the cover letter. The reasons for this patch set are: * The multiplier is fundamentally a heuristic. Nora raised the same concern in the v1 round of the earlier series(<https://lists.denx.de/pipermail/u-boot/2026-June/621575.html>): "Deriving a buffer size from the compressed size is not possible, as the compression ratio may be arbitrarily high for data with many repetitions (for example ranges of 0x00 or 0xff)."She dropped her replacement patch when we bumped 4x to 8x, but the underlying point stands: any fixed factor can be defeated by a highly compressible payload, and further bumps are just moving the ceiling. * Simon suggested the header-size approach as the principled fix in the same round (<https://lists.denx.de/pipermail/u-boot/2026-May/620121.html>): "It might be worth updating image_decomp() to take a ulong size... I believe in each case it is also possible to find out the decomp size by looking at the header." So the growth buys correctness: the buffer size is derived from the compressed stream itself, not from a multiplier guess that can be defeated by any payload with a high enough compression ratio. That said, I understand the "we're not seeing it" concern. If you would rather wait for a concrete report, I am happy to drop the series and re-send when one lands, or to shrink patch 1 to gzip only, which cuts about 40 lines of parser code. Let me know which you prefer. > > -- > Tom Best Regards, Aristo
