Re: LZ4 : fix the data abort issue.

Re: LZ4 : fix the data abort issue.

[Yeon, JeHyeon (Tom)]

If the part of the compression data are corrupted, or the compression
data is totally fake, the memory access over the limit is possible.

This is the log from my system usning lz4 decompression.
   [6502]data abort, halting
   [6503]r0  0x00000000 r1  0x00000000 r2  0xdcea0ffc r3  0xdcea0ffc
   [6509]r4  0xb9ab0bfd r5  0xdcea0ffc r6  0xdcea0ff8 r7  0xdce80000
   [6515]r8  0x00000000 r9  0x00000000 r10 0x00000000 r11 0xb9a98000
   [6522]r12 0xdcea1000 usp 0x00000000 ulr 0x00000000 pc  0x820149bc
   [6528]spsr 0x400001f3
and the memory addresses of some variables at the moment are
    ref:0xdcea0ffc, op:0xdcea0ffc, oend:0xdcea1000

As you can see, COPYLENGH is 8bytes, so @ref and @op can access the momory
over @oend.

Signed-off-by: tom.yeon <tom.yeon@windriver.com>
---
 lib/lz4/lz4_decompress.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
index 7a85967..f0f5c5c 100644
--- a/lib/lz4/lz4_decompress.c
+++ b/lib/lz4/lz4_decompress.c
@@ -139,6 +139,9 @@ static int lz4_uncompress(const char *source, char *dest, int osize)
 			/* Error: request to write beyond destination buffer */
 			if (cpy > oend)
 				goto _output_error;
+			if ((ref + COPYLENGTH) > oend ||
+					(op + COPYLENGTH) > oend)
+				goto _output_error;
 			LZ4_SECURECOPY(ref, op, (oend - COPYLENGTH));
 			while (op < cpy)
 				*op++ = *ref++;
-- 
1.7.9.5

Re: LZ4 : fix the data abort issue.

[David Sterba]

On Thu, Mar 12, 2015 at 08:28:55AM +0000, Yeon, JeHyeon (Tom) wrote:
> If the part of the compression data are corrupted, or the compression
> data is totally fake, the memory access over the limit is possible.
> 
> This is the log from my system usning lz4 decompression.
>    [6502]data abort, halting
>    [6503]r0  0x00000000 r1  0x00000000 r2  0xdcea0ffc r3  0xdcea0ffc
>    [6509]r4  0xb9ab0bfd r5  0xdcea0ffc r6  0xdcea0ff8 r7  0xdce80000
>    [6515]r8  0x00000000 r9  0x00000000 r10 0x00000000 r11 0xb9a98000
>    [6522]r12 0xdcea1000 usp 0x00000000 ulr 0x00000000 pc  0x820149bc
>    [6528]spsr 0x400001f3
> and the memory addresses of some variables at the moment are
>     ref:0xdcea0ffc, op:0xdcea0ffc, oend:0xdcea1000
> 
> As you can see, COPYLENGH is 8bytes, so @ref and @op can access the momory
> over @oend.
> 
> Signed-off-by: tom.yeon <tom.yeon@windriver.com>

Reviewed-by: David Sterba <dsterba@suse.cz>

Matches implementation in lz4 upstream.

Btw, why is it a reply and not a standalone patch? I don't seem to find
any prior message in relevant mailinglists.

Re: LZ4 : fix the data abort issue.

[gregkh]

On Thu, Mar 12, 2015 at 08:28:55AM +0000, Yeon, JeHyeon (Tom) wrote:
> If the part of the compression data are corrupted, or the compression
> data is totally fake, the memory access over the limit is possible.
> 
> This is the log from my system usning lz4 decompression.
>    [6502]data abort, halting
>    [6503]r0  0x00000000 r1  0x00000000 r2  0xdcea0ffc r3  0xdcea0ffc
>    [6509]r4  0xb9ab0bfd r5  0xdcea0ffc r6  0xdcea0ff8 r7  0xdce80000
>    [6515]r8  0x00000000 r9  0x00000000 r10 0x00000000 r11 0xb9a98000
>    [6522]r12 0xdcea1000 usp 0x00000000 ulr 0x00000000 pc  0x820149bc
>    [6528]spsr 0x400001f3
> and the memory addresses of some variables at the moment are
>     ref:0xdcea0ffc, op:0xdcea0ffc, oend:0xdcea1000
> 
> As you can see, COPYLENGH is 8bytes, so @ref and @op can access the momory
> over @oend.
> 
> Signed-off-by: tom.yeon <tom.yeon@windriver.com>

I need a "real" name here, I somehow doubt that your government
documents has your name as "tom.yeon", right?

Please fix this up and resend so that I can apply it.

thanks,

greg k-h

회신: LZ4 : fix the data abort issue.

[Yeon, JeHyeon (Tom)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="ks_c_5601-1987", Size: 3073 bytes --]

If the part of the compression data are corrupted, or the compression
data is totally fake, the memory access over the limit is possible.

This is the log from my system usning lz4 decompression.
   [6502]data abort, halting
   [6503]r0  0x00000000 r1  0x00000000 r2  0xdcea0ffc r3  0xdcea0ffc
   [6509]r4  0xb9ab0bfd r5  0xdcea0ffc r6  0xdcea0ff8 r7  0xdce80000
   [6515]r8  0x00000000 r9  0x00000000 r10 0x00000000 r11 0xb9a98000
   [6522]r12 0xdcea1000 usp 0x00000000 ulr 0x00000000 pc  0x820149bc
   [6528]spsr 0x400001f3
and the memory addresses of some variables at the moment are
    ref:0xdcea0ffc, op:0xdcea0ffc, oend:0xdcea1000

As you can see, COPYLENGH is 8bytes, so @ref and @op can access the momory
over @oend.

Signed-off-by: JeHyeon Yeon <tom.yeon@windriver.com>
---
 lib/lz4/lz4_decompress.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
index 7a85967..f0f5c5c 100644
--- a/lib/lz4/lz4_decompress.c
+++ b/lib/lz4/lz4_decompress.c
@@ -139,6 +139,9 @@ static int lz4_uncompress(const char *source, char *dest, int osize)
 			/* Error: request to write beyond destination buffer */
 			if (cpy > oend)
 				goto _output_error;
+			if ((ref + COPYLENGTH) > oend ||
+					(op + COPYLENGTH) > oend)
+				goto _output_error;
 			LZ4_SECURECOPY(ref, op, (oend - COPYLENGTH));
 			while (op < cpy)
 				*op++ = *ref++;
-- 
1.7.9.5



Dear greg k-h
I usually use my English name as tom.
But my real name is not tom as you told me but JeHyeon Yeon.
So, I changed my signed-off from tom.yeon to JeHyeon Yeon.
Thank you.
________________________________________
º¸³½ »ç¶÷: gregkh@linuxfoundation.org [gregkh@linuxfoundation.org]
º¸³½ ³¯Â¥: 2015³â 3¿ù 13ÀÏ ±Ý¿äÀÏ ¿ÀÈÄ 10:23
¹Þ´Â »ç¶÷: Yeon, JeHyeon (Tom)
ÂüÁ¶: linux-kernel@vger.kernel.org
Á¦¸ñ: Re: LZ4 : fix the data abort issue.

On Thu, Mar 12, 2015 at 08:28:55AM +0000, Yeon, JeHyeon (Tom) wrote:
> If the part of the compression data are corrupted, or the compression
> data is totally fake, the memory access over the limit is possible.
>
> This is the log from my system usning lz4 decompression.
>    [6502]data abort, halting
>    [6503]r0  0x00000000 r1  0x00000000 r2  0xdcea0ffc r3  0xdcea0ffc
>    [6509]r4  0xb9ab0bfd r5  0xdcea0ffc r6  0xdcea0ff8 r7  0xdce80000
>    [6515]r8  0x00000000 r9  0x00000000 r10 0x00000000 r11 0xb9a98000
>    [6522]r12 0xdcea1000 usp 0x00000000 ulr 0x00000000 pc  0x820149bc
>    [6528]spsr 0x400001f3
> and the memory addresses of some variables at the moment are
>     ref:0xdcea0ffc, op:0xdcea0ffc, oend:0xdcea1000
>
> As you can see, COPYLENGH is 8bytes, so @ref and @op can access the momory
> over @oend.
>
> Signed-off-by: tom.yeon <tom.yeon@windriver.com>

I need a "real" name here, I somehow doubt that your government
documents has your name as "tom.yeon", right?

Please fix this up and resend so that I can apply it.

thanks,

greg k-h
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥