From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 02F4C344DB9 for ; Tue, 28 Jul 2026 03:46:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785210404; cv=none; b=P8uSMpxRID5tTWlFp6b87UydNvEP/N/e8di43SjdY1jWUWLLm0QhO+BIS+oFR6qnTYal8u0/Nr0wySaaWatDNRnMy9X2cJ44MMOYexUZPIGhCB+93TaIIJqobgvyz4lWnfFX3s94VNCwKJtl9AMLvVok+r6PXKG9nzIJhQW4xrM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785210404; c=relaxed/simple; bh=Ap9437QP+mwKPQIwVlce6STfN7n7PdRW9Q+5MB1Fshg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=tYBDVPgBfo9UFWksQiUipNmtUR+FsyJdc7FUaEyt+fZLVzDJOFZRRcT3bSy7Y34ZUDKYV2474qNqYGqsFZFCEWLo6xNxFP+oFbwsliPB+swEETcw34NJMCpV91WQbQ+7Ybm7iGSrVZPHFtbzXiBZwH7Mf9//F2Wp7XqNgQCms+o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R4+JufGQ; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="R4+JufGQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3220D1F000E9; Tue, 28 Jul 2026 03:46:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785210402; bh=7U3zlkmh8Pc/euVyLT92bNgOkXi7m38doJdTHNiz8Oo=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=R4+JufGQAJvdqXwgt7253Ur/g1EsExQHm2yDYFqVoC3Un9WRKzJhvmOcFJSVp8K1A cBEAMEXeWI77ixGCoV8x4IzFmUewDP/rKE0fIUi0G98hIwitAzMGI92czR4If6jxvn oi2VEMAHjiJdV872qMrUh4SrqBLn0qOyxZ4cm2orqlPWFrYZdShX/yazWjRgEilLMd O/6gZP9h1ttWRsvfR7wQkyNu9WHEN3CU563iusfA8cXIzK+fmcGLz9aB99F5fYD9qe 7v7OGJwGS288sbL2U/HhFBhRIGrPlQsEwWV/Uk6i1ccYPb2NvCLolUcz72ONfQ4yEx KoqJwdeqTn7Ug== From: SJ Park To: Gao Xiang Cc: SJ Park , Michael Bommarito , Yue Hu , Jeffle Xu , Sandeep Dhavale , Chunhai Guo , linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, Gao Xiang , Chao Yu Subject: Re: [PATCH v3] erofs: cap LZMA stream pool size Date: Mon, 27 Jul 2026 20:46:32 -0700 Message-ID: <20260728034633.104580-1-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <6179ba55-d53d-4c46-8220-d7340f18e8b5@linux.alibaba.com> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello, On Tue, 21 Jul 2026 11:44:04 +0800 Gao Xiang 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 > > > I submitted the following version to -next: > > From 4ec57610a769cd93027d12134c75160390b23b08 Mon Sep 17 00:00:00 2001 > From: Michael Bommarito > 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 > Reviewed-by: Gao Xiang > Signed-off-by: Gao Xiang > --- > 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 [...]