On Mon, Apr 04, 2022 at 02:21:23PM -0700, Andrew Morton wrote:Sorry for my missspelling, Gao Xiang is right, i mean "well-designed corrupted".
On Sat, 2 Apr 2022 12:55:39 +0800 Gao Xiang <hsiangkao@xxxxxxxxxxxxxxxxx> wrote:
On Fri, Nov 19, 2021 at 06:23:24PM +0000, Nick Terrell wrote:Sorry, I'd not noticed that this was from lz4 upstream.
Acked-by: Gao Xiang <hsiangkao@xxxxxxxxxxxxxxxxx>
On Nov 11, 2021, at 2:50 AM, Guo Xuenan <guoxuenan@xxxxxxxxxx> wrote:Sorry I’m a bit late to the party, but this looks good to me!
When partialDecoding, it is EOF if we've either, filled the output
buffer or can't proceed with reading an offset for following match.
In some extreme corner cases when compressed data is crusted corrupted,
UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial
may lead to read out of bound problem during decoding. lz4 upstream has
fixed it [2] and this issue has been disscussed here [3] before.
current decompression routine was ported from lz4 v1.8.3, bumping lib/lz4
to v1.9.+ is certainly a huge work to be done later, so, we'd better fix
it first.
[1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@xxxxxxxxxx/
[2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#
[3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@xxxxxx/
Reported-by: syzbot+63d688f1d899c588fb71@xxxxxxxxxxxxxxxxxxxxxxxxx
Cc: hsiangkao@xxxxxxxxxxxxxxxxx
Cc: terrelln@xxxxxx
Cc: cyan@xxxxxx
Cc: cy.fan@xxxxxxxxxx
Signed-off-by: Guo Xuenan <guoxuenan@xxxxxxxxxx>
Reviewed-by: Nick Terrell <terrelln@xxxxxx>
Hi Andrew,
This patch has already been pending for 2 release cycles.. Would you
mind submitting it upstream? Or are there other concerns about this?
I'll put a cc:stable in there and shall send it upstream this week.
In the changelog, can someone please explain what "crusted corrupted"
is saying?
Er.. It sounds like "well-designed corrupted". I think it was a typoThanks,
though.
Thanks,
Gao Xiang
.