Message-ID: <sashiko-outbox-201615@kernel.org>
From: sashiko-bot@kernel.org
Subject: Re: [PATCH v2 07/15] lib/lz4: backport upstream's match length
 limit fix
Reply-To: sashiko-reviews@lists.linux.dev
To: "Michal Wilczynski" <m.wilczynski@samsung.com>
Cc: linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>, "Vasily
 Gorbik" <gor@linux.ibm.com>, "Alexander Gordeev" <agordeev@linux.ibm.com>, "Christian
 Borntraeger" <borntraeger@linux.ibm.com>
In-Reply-To: <20261106-lz4-vendor-upstream-v2-7-ee04c3f0d7dc@samsung.com>
References: <20261106-lz4-vendor-upstream-v2-0-ee04c3f0d7dc@samsung.com>
 <CGME20261106144259eucas1p27d26efbc44beac102c03ec07ebed4310@eucas1p2.samsung.com>
 <20261106-lz4-vendor-upstream-v2-7-ee04c3f0d7dc@samsung.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Fri, 06 Nov 2026 14:50:11 +0000
Precedence: list

> v1.10.0 lets a match length's extension bytes run to four bytes before
> the end of the block, which leaves room for only a token and three
> literals where the format requires five. The fork rejected such blocks,
> v1.10.0 decodes them: 1f 41 01 00 ff 00 30 7a 7a 7a decodes to 278
> bytes instead of failing.
>=20
> Upstream fixed this in 587ed9557708 ("add comments explaining
> read_variable_length() ilimit bounds, fix match length limit"), on top
> of a read_variable_length() rework v1.10.0 does not have. Both versions
> accept the same final ip for a given limit, so change the limit at the
> two match length call sites to iend - (1 + LASTLITERALS), as upstream
> does. This is one byte stricter than the fork; no compressor produces
> the blocks it newly rejects.
>=20
> This goes away at the next re-sync.
>=20
> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>

Sashiko has reviewed this patch and found no issues.

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20261106-lz4-vendor=
-upstream-v2-0-ee04c3f0d7dc@samsung.com?part=3D7