Re: [PATCH v3] erofs: cap LZMA stream pool size

[SJ Park <sj@kernel.org>]

Hello,

On Tue, 21 Jul 2026 11:44:04 +0800 Gao Xiang <hsiangkao@linux.alibaba.com> wrote:

> Hi Machael,
> 
> On 2026/7/17 11:43, Gao Xiang wrote:
> > 
> > 
> > On 2026/7/14 19:47, Michael Bommarito wrote:
> >> fs/erofs/decompressor_lzma.c sizes the module-global MicroLZMA stream
> >> pool from num_possible_cpus() when the lzma_streams module parameter is
> >> unset, then z_erofs_load_lzma_config() preallocates one image-supplied
> >> dictionary per stream, accepting dictionaries up to 8 MiB.  On high-CPU
> >> systems, a small EROFS image can pin hundreds of MiB of vmalloc-backed
> >> decoder state until the erofs module is unloaded.
> >>
> >> Impact: an attacker-supplied EROFS image mounted by the system can pin up
> >> to 8 MiB times the LZMA stream count of kernel vmalloc memory.
> >>
> >> Bound the default stream count by a new
> >> CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS option, default 16, so the
> >> worst-case default preallocation is 128 MiB while preserving the existing
> >> per-image dictionary limit.  An explicit lzma_streams module parameter is
> >> still honoured as-is, so administrators who deliberately size the pool are
> >> not affected.
> >>
> >> Fixes: 622ceaddb764 ("erofs: lzma compression support")
> >> Cc: stable@vger.kernel.org
> >> Assisted-by: Claude:claude-opus-4-8
> >> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> > 
> I submitted the following version to -next:
> 
>  From 4ec57610a769cd93027d12134c75160390b23b08 Mon Sep 17 00:00:00 2001
> From: Michael Bommarito <michael.bommarito@gmail.com>
> Date: Tue, 14 Jul 2026 07:47:29 -0400
> Subject: erofs: cap LZMA stream pool size
> 
> fs/erofs/decompressor_lzma.c sizes the module-global MicroLZMA stream
> pool from num_possible_cpus() when the lzma_streams module parameter is
> unset, then z_erofs_load_lzma_config() preallocates one image-supplied
> dictionary per stream, accepting dictionaries up to 8 MiB.  On high-CPU
> systems, a small EROFS image can pin hundreds of MiB of vmalloc-backed
> decoder state until the erofs module is unloaded.
> 
> Impact: An EROFS image mounted by the system can pin up to 8 MiB of
> vmalloc memory per LZMA stream, either as intended or unexpectedly.
> 
> Bound the default stream count by a new
> CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS option, default 16, so the
> worst-case default preallocation is 128 MiB if the number of CPUs is no
> less than 16 while preserving the existing per-image dictionary limit.
> An explicit lzma_streams module parameter is still honoured as-is, so
> administrators who deliberately size the pool are not affected.
> 
> Fixes: 622ceaddb764 ("erofs: lzma compression support")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
> ---
>   fs/erofs/Kconfig             | 14 ++++++++++++++
>   fs/erofs/decompressor_lzma.c |  3 ++-
>   2 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/erofs/Kconfig b/fs/erofs/Kconfig
> index 4789b1077d8ce..36f027c1c5ac5 100644
> --- a/fs/erofs/Kconfig
> +++ b/fs/erofs/Kconfig
> @@ -131,6 +131,20 @@ config EROFS_FS_ZIP_LZMA
>   
>   	  Say N if you want to disable LZMA compression support.
>   
> +config EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS
> +	int "EROFS LZMA default maximum decompression streams"
> +	depends on EROFS_FS_ZIP_LZMA
> +	range 1 NR_CPUS

Hello, I just found this breaks CONFIG_NR_CPUS undefined builds.  For example,
my m68k build test [1] shows problems like below:

    $ build_m68k_w1.sh
    [...]
    fs/erofs/Kconfig:137:warning: range is invalid
    .config:13480:warning: symbol value 'NR_CPUS' invalid for EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS

I confirmed using 1024 as the upperlimit of the range, like the original patch,
fixes the problem.  I'm not sure if that's the right and preferred fix, though.
I'm just reporting my finding.

[1] https://github.com/damonitor/damon-tests/blob/master/corr/tests/build_m68k_w1.sh


Thanks,
SJ

[...]