All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Terrell <terrelln@fb.com>
To: Paul Cercueil <paul@crapouillou.net>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"od@zcrc.me" <od@zcrc.me>
Subject: Re: [PATCH 1/2] lib: decompress_unzstd: Limit output size
Date: Mon, 24 Aug 2020 20:11:12 +0000	[thread overview]
Message-ID: <8E3C6FC0-2DF0-49B5-9885-BA4AC81A117D@fb.com> (raw)
In-Reply-To: <20200821162948.146947-1-paul@crapouillou.net>



> On Aug 21, 2020, at 9:29 AM, Paul Cercueil <paul@crapouillou.net> wrote:
> 
> The zstd decompression code, as it is right now, will have internal
> values overflow on 32-bit systems when the output size is LONG_MAX.
> 
> Until someone smarter than me can figure out how to fix the zstd code
> properly, limit the destination buffer size to 512 MiB, which should be
> enough for everybody, in order to make it usable on 32-bit systems.

Can you bump the size up to 2GB? I suspect the problem inside of zstd
is an off-by-one error or something similar, so getting closer to the limit
shouldn't be a problem. I’d feel more comfortable with 2GB, since
kernels can get pretty large.

Hmm, zstd shouldn’t be overflowing that value. I’m currently preparing
a patch to updating the version of zstd in the kernel, and using upstream
directly. I will add a test upstream in 32-bit mode to ensure that we don’t
overflow a 32-bit size_t, so this will be fixed after the update.

-Nick

> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
> lib/decompress_unzstd.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/decompress_unzstd.c b/lib/decompress_unzstd.c
> index 0ad2c15479ed..e1c03b1eaa6e 100644
> --- a/lib/decompress_unzstd.c
> +++ b/lib/decompress_unzstd.c
> @@ -77,6 +77,7 @@
> 
> #include <linux/decompress/mm.h>
> #include <linux/kernel.h>
> +#include <linux/sizes.h>
> #include <linux/zstd.h>
> 
> /* 128MB is the maximum window size supported by zstd. */
> @@ -179,7 +180,7 @@ static int INIT __unzstd(unsigned char *in_buf, long in_len,
> 	size_t ret;
> 
> 	if (out_len == 0)
> -		out_len = LONG_MAX; /* no limit */
> +		out_len = SZ_512M; /* should be big enough, right? */
> 
> 	if (fill == NULL && flush == NULL)
> 		/*
> -- 
> 2.28.0
> 


  parent reply	other threads:[~2020-08-24 20:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-21 16:29 [PATCH 1/2] lib: decompress_unzstd: Limit output size Paul Cercueil
2020-08-21 16:29 ` [PATCH 2/2] MIPS: Add support for ZSTD-compressed kernels Paul Cercueil
2020-08-24 19:51   ` Nick Terrell
2020-08-24 21:02     ` Paul Cercueil
2020-08-24 21:45       ` Nick Terrell
2020-08-24 20:11 ` Nick Terrell [this message]
2020-08-24 21:05   ` [PATCH 1/2] lib: decompress_unzstd: Limit output size Paul Cercueil
2020-08-24 21:50     ` Nick Terrell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8E3C6FC0-2DF0-49B5-9885-BA4AC81A117D@fb.com \
    --to=terrelln@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=od@zcrc.me \
    --cc=paul@crapouillou.net \
    --cc=tsbogend@alpha.franken.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.