When partialDecoding, it is EOF if we've either, filled the output
buffer or can't proceed with reading an offset for following match.
As reported by KASAN[1], LZ4_decompress_safe_partial may lead
to erofs decoding read out of bound. Fortunately, lz4 upstream has
fixed it [2]. current decompression routine was ported from lz4 v1.8.3,
so, we can fix it, before bumping lib/lz4 to v1.9.+.
[1] https://syzkaller.appspot.com/bug?extid=63d688f1d899c588fb71
[2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#
Reported-by: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Guo Xuenan <[email protected]>
---
lib/lz4/lz4_decompress.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
index 926f4823d5ea..fd1728d94bab 100644
--- a/lib/lz4/lz4_decompress.c
+++ b/lib/lz4/lz4_decompress.c
@@ -271,8 +271,12 @@ static FORCE_INLINE int LZ4_decompress_generic(
ip += length;
op += length;
- /* Necessarily EOF, due to parsing restrictions */
- if (!partialDecoding || (cpy == oend))
+ /* Necessarily EOF when !partialDecoding.
+ * When partialDecoding, it is EOF if we've either
+ * filled the output buffer or
+ * can't proceed with reading an offset for following match.
+ */
+ if (!partialDecoding || (cpy == oend) || (ip >= (iend - 2)))
break;
} else {
/* may overwrite up to WILDCOPYLENGTH beyond cpy */
--
2.31.1
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 crupted, 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/netdev/[email protected]/
[2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#
[3] https://lore.kernel.org/all/[email protected]/
Reported-by: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Guo Xuenan <[email protected]>
---
lib/lz4/lz4_decompress.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
index 926f4823d5ea..fd1728d94bab 100644
--- a/lib/lz4/lz4_decompress.c
+++ b/lib/lz4/lz4_decompress.c
@@ -271,8 +271,12 @@ static FORCE_INLINE int LZ4_decompress_generic(
ip += length;
op += length;
- /* Necessarily EOF, due to parsing restrictions */
- if (!partialDecoding || (cpy == oend))
+ /* Necessarily EOF when !partialDecoding.
+ * When partialDecoding, it is EOF if we've either
+ * filled the output buffer or
+ * can't proceed with reading an offset for following match.
+ */
+ if (!partialDecoding || (cpy == oend) || (ip >= (iend - 2)))
break;
} else {
/* may overwrite up to WILDCOPYLENGTH beyond cpy */
--
2.31.1
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/[email protected]/
[2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#
[3] https://lore.kernel.org/all/[email protected]/
Reported-by: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Guo Xuenan <[email protected]>
---
lib/lz4/lz4_decompress.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
index 926f4823d5ea..fd1728d94bab 100644
--- a/lib/lz4/lz4_decompress.c
+++ b/lib/lz4/lz4_decompress.c
@@ -271,8 +271,12 @@ static FORCE_INLINE int LZ4_decompress_generic(
ip += length;
op += length;
- /* Necessarily EOF, due to parsing restrictions */
- if (!partialDecoding || (cpy == oend))
+ /* Necessarily EOF when !partialDecoding.
+ * When partialDecoding, it is EOF if we've either
+ * filled the output buffer or
+ * can't proceed with reading an offset for following match.
+ */
+ if (!partialDecoding || (cpy == oend) || (ip >= (iend - 2)))
break;
} else {
/* may overwrite up to WILDCOPYLENGTH beyond cpy */
--
2.31.1
> On Nov 11, 2021, at 2:50 AM, Guo Xuenan <[email protected]> wrote:
>
> 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/[email protected]/
> [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#
> [3] https://lore.kernel.org/all/[email protected]/
>
> Reported-by: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Signed-off-by: Guo Xuenan <[email protected]>
Sorry I’m a bit late to the party, but this looks good to me!
Reviewed-by: Nick Terrell <[email protected]>
> ---
> lib/lz4/lz4_decompress.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
> index 926f4823d5ea..fd1728d94bab 100644
> --- a/lib/lz4/lz4_decompress.c
> +++ b/lib/lz4/lz4_decompress.c
> @@ -271,8 +271,12 @@ static FORCE_INLINE int LZ4_decompress_generic(
> ip += length;
> op += length;
>
> - /* Necessarily EOF, due to parsing restrictions */
> - if (!partialDecoding || (cpy == oend))
> + /* Necessarily EOF when !partialDecoding.
> + * When partialDecoding, it is EOF if we've either
> + * filled the output buffer or
> + * can't proceed with reading an offset for following match.
> + */
> + if (!partialDecoding || (cpy == oend) || (ip >= (iend - 2)))
> break;
> } else {
> /* may overwrite up to WILDCOPYLENGTH beyond cpy */
> --
> 2.31.1
>
On Mon, Apr 04, 2022 at 02:21:23PM -0700, Andrew Morton wrote:
> On Sat, 2 Apr 2022 12:55:39 +0800 Gao Xiang <[email protected]> wrote:
>
> > On Fri, Nov 19, 2021 at 06:23:24PM +0000, Nick Terrell wrote:
> > >
> > >
> > > > On Nov 11, 2021, at 2:50 AM, Guo Xuenan <[email protected]> wrote:
> > > >
> > > > 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/[email protected]/
> > > > [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#
> > > > [3] https://lore.kernel.org/all/[email protected]/
> > > >
> > > > Reported-by: [email protected]
> > > > Cc: [email protected]
> > > > Cc: [email protected]
> > > > Cc: [email protected]
> > > > Cc: [email protected]
> > > > Signed-off-by: Guo Xuenan <[email protected]>
> > >
> > > Sorry I’m a bit late to the party, but this looks good to me!
> > >
> > > Reviewed-by: Nick Terrell <[email protected]>
> >
> > Acked-by: Gao Xiang <[email protected]>
> >
> > 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?
>
> Sorry, I'd not noticed that this was from lz4 upstream.
>
> 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 typo
though.
Thanks,
Gao Xiang
On Sat, 2 Apr 2022 12:55:39 +0800 Gao Xiang <[email protected]> wrote:
> On Fri, Nov 19, 2021 at 06:23:24PM +0000, Nick Terrell wrote:
> >
> >
> > > On Nov 11, 2021, at 2:50 AM, Guo Xuenan <[email protected]> wrote:
> > >
> > > 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/[email protected]/
> > > [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#
> > > [3] https://lore.kernel.org/all/[email protected]/
> > >
> > > Reported-by: [email protected]
> > > Cc: [email protected]
> > > Cc: [email protected]
> > > Cc: [email protected]
> > > Cc: [email protected]
> > > Signed-off-by: Guo Xuenan <[email protected]>
> >
> > Sorry I’m a bit late to the party, but this looks good to me!
> >
> > Reviewed-by: Nick Terrell <[email protected]>
>
> Acked-by: Gao Xiang <[email protected]>
>
> 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?
Sorry, I'd not noticed that this was from lz4 upstream.
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?
On Fri, Nov 19, 2021 at 06:23:24PM +0000, Nick Terrell wrote:
>
>
> > On Nov 11, 2021, at 2:50 AM, Guo Xuenan <[email protected]> wrote:
> >
> > 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/[email protected]/
> > [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#
> > [3] https://lore.kernel.org/all/[email protected]/
> >
> > Reported-by: [email protected]
> > Cc: [email protected]
> > Cc: [email protected]
> > Cc: [email protected]
> > Cc: [email protected]
> > Signed-off-by: Guo Xuenan <[email protected]>
>
> Sorry I’m a bit late to the party, but this looks good to me!
>
> Reviewed-by: Nick Terrell <[email protected]>
Acked-by: Gao Xiang <[email protected]>
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?
Many thanks!
Gao Xiang
Hi all，
在 2022/4/5 6:28, Gao Xiang Write:
> On Mon, Apr 04, 2022 at 02:21:23PM -0700, Andrew Morton wrote:
>> On Sat, 2 Apr 2022 12:55:39 +0800 Gao Xiang <[email protected]> wrote:
>>
>>> On Fri, Nov 19, 2021 at 06:23:24PM +0000, Nick Terrell wrote:
>>>>
>>>>> On Nov 11, 2021, at 2:50 AM, Guo Xuenan <[email protected]> wrote:
>>>>>
>>>>> 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/[email protected]/
>>>>> [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#
>>>>> [3] https://lore.kernel.org/all/[email protected]/
>>>>>
>>>>> Reported-by: [email protected]
>>>>> Cc: [email protected]
>>>>> Cc: [email protected]
>>>>> Cc: [email protected]
>>>>> Cc: [email protected]
>>>>> Signed-off-by: Guo Xuenan <[email protected]>
>>>> Sorry I’m a bit late to the party, but this looks good to me!
>>>>
>>>> Reviewed-by: Nick Terrell <[email protected]>
>>> Acked-by: Gao Xiang <[email protected]>
>>>
>>> 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?
>> Sorry, I'd not noticed that this was from lz4 upstream.
>>
>> 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?
Sorry for my missspelling, Gao Xiang is right, i mean "well-designed
corrupted".
> Er.. It sounds like "well-designed corrupted". I think it was a typo
> though.
>
> Thanks,
> Gao Xiang
> .
Thanks,
Guo Xuenan
.