Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Nick Terrell <terrelln@fb.com>
To:     Paul Cercueil <paul@crapouillou.net>
CC:     Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
        "od@zcrc.me" <od@zcrc.me>,
        "linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 1/2] lib: decompress_unzstd: Limit output size
Thread-Topic: [PATCH v3 1/2] lib: decompress_unzstd: Limit output size
Thread-Index: AQHWgGwCgxByMrx6Qka7tKhSQVK176lUYWWA
Date:   Tue, 1 Sep 2020 22:42:08 +0000
Message-ID: <747B4847-08E5-40C9-927B-E1BAC057CF46@fb.com>
References: <20200901142651.1165237-1-paul@crapouillou.net>
 <20200901142651.1165237-2-paul@crapouillou.net>
In-Reply-To: <20200901142651.1165237-2-paul@crapouillou.net>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <89AA661875F82C44BD6E153981C3C528@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a9349a92-7507-4ad5-4665-08d84ec84270
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2020 22:42:08.5506
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Drt6I0u+LlGpKmyc1QigMeyV9j0pOnbR/H6IlSi7hj+yPMjKJsUb2CXFuG/PH6T8
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2950
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687
 definitions=2020-09-01_10:2020-09-01,2020-09-01 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 bulkscore=0 adultscore=0
 mlxlogscore=999 impostorscore=0 spamscore=0 phishscore=0 suspectscore=0
 mlxscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1015
 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2006250000 definitions=main-2009010190
X-FB-Internal: deliver
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Sep 1, 2020, at 7:26 AM, Paul Cercueil <paul@crapouillou.net> wrote:
>=20
> The zstd decompression code, as it is right now, will most likely fail
> on 32-bit systems, as the default output buffer size causes the buffer's
> end address to overflow.
>=20
> Address this issue by setting a sane default to the default output size,
> with a value that won't overflow the buffer's end address.
>=20
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
>=20
> Notes:
>    v2: Change limit to 1 GiB
>=20
>    v3: Compute size limit instead of using hardcoded value
>=20
> lib/decompress_unzstd.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>=20
> diff --git a/lib/decompress_unzstd.c b/lib/decompress_unzstd.c
> index 0ad2c15479ed..790abc472f5b 100644
> --- a/lib/decompress_unzstd.c
> +++ b/lib/decompress_unzstd.c
> @@ -178,8 +178,13 @@ static int INIT __unzstd(unsigned char *in_buf, long=
 in_len,
> 	int err;
> 	size_t ret;
>=20
> +	/*
> +	 * ZSTD decompression code won't be happy if the buffer size is so big
> +	 * that its end address overflows. When the size is not provided, make
> +	 * it as big as possible without having the end address overflow.
> +	 */
> 	if (out_len =3D=3D 0)
> -		out_len =3D LONG_MAX; /* no limit */
> +		out_len =3D UINTPTR_MAX - (uintptr_t)out_buf;

Great, that works for me. Thanks for fixing this!

Reviewed-by: Nick Terrell <terrelln@fb.com>

> 	if (fill =3D=3D NULL && flush =3D=3D NULL)
> 		/*
> --=20
> 2.28.0
>=20