public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kolasa <kkolasa@winsoft.pl>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: dsterba@suse.cz, tom.yeon@windriver.com, linux-kernel@vger.kernel.org
Subject: Re: lz4: fix system halted at boot kernel x86_64 compressed lz4
Date: Fri, 3 Apr 2015 13:33:54 +0200	[thread overview]
Message-ID: <551E7AA2.1050206@winsoft.pl> (raw)
In-Reply-To: <20150331152245.GB11455@kroah.com>

On 31.03.2015 17:22, Greg KH wrote:
> On Wed, Mar 25, 2015 at 08:04:59AM +0100, Krzysztof Kolasa wrote:
>> On 25.03.2015 01:44, David Sterba wrote:
>>> On Tue, Mar 24, 2015 at 12:27:25PM +0100, Krzysztof Kolasa wrote:
>>>> lz4: fix system halted at boot kernel x86_64 compressed lz4
>>>>
>>>> Decompression process ends with an error when loading kernel:
>>>>
>>>> Decoding failed
>>>>  -- System halted
>>> Serious regression detected ...
>>>
>>>> This condition is probably not needed ( from the last commit d5e7caf) :
>>> The offending patch is on the way to stable trees, so it would be best
>>> to postpone it for now.
>>>
>>>> if( ... ||
>>>>     (op + COPYLENGTH) > oend)
>>>>     goto _output_error
>>>>
>>>> macro LZ4_SECURE_COPY() tests op and does not copy any data
>>>> when op exceeds the value, decompression process is continued.
>>>>
>>>> added by analogy security for the ref:
>>>>
>>>> if ((ref + COPYLENGTH) > oend...
>>>>
>>>> to lz4_uncompress_unknownoutputsize(...)
>>> I did only a quick check, your analysis seems correct. Reviewing the lz4
>>> patches is tedious as the kernel implementations do not match the
>>> upstream one line-by-line besides that I've missed the side effects of
>>> the macro.
>>>
>> Add patch source for review (send to LKML) :
>> ---------------------
>>
>> lz4: fix system halted at boot kernel x86_64 compressed lz4
>>
>> Decompression process ends with an error when loading kernel:
>>
>> Decoding failed
>>  -- System halted
>>
>> This condition is probably not needed ( from the last commit d5e7caf) :
>>
>> if( ... ||
>>     (op + COPYLENGTH) > oend)
>>     goto _output_error
>>
>> macro LZ4_SECURE_COPY() tests op and does not copy any data
>> when op exceeds the value, decompression process is continued.
>>
>> added by analogy security for the ref:
>>
>> if ((ref + COPYLENGTH) > oend...
>>
>> to lz4_uncompress_unknownoutputsize(...)
>>
>> Signed-off-by: Krzysztof Kolasa <kkolasa@winsoft.pl>
>> ---
>>  lib/lz4/lz4_decompress.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
>> index f0f5c5c..e248c4e 100644
>> --- a/lib/lz4/lz4_decompress.c
>> +++ b/lib/lz4/lz4_decompress.c
>> @@ -139,8 +139,7 @@ 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)
>> +            if ((ref + COPYLENGTH) > oend)
>>                  goto _output_error;
>>              LZ4_SECURECOPY(ref, op, (oend - COPYLENGTH));
>>              while (op < cpy)
>> @@ -270,6 +269,8 @@ static int lz4_uncompress_unknownoutputsize(const char *source, char *dest,
>>          if (cpy > oend - COPYLENGTH) {
>>              if (cpy > oend)
>>                  goto _output_error; /* write outside of buf */
>> +            if ((ref + COPYLENGTH) > oend)
>> +                goto _output_error;
>>  
>>              LZ4_SECURECOPY(ref, op, (oend - COPYLENGTH));
>>              while (op < cpy)
>> -- 2.3.3.dirty
> I'm confused, what is the problem here?  What went wrong with the
x86_64 lz4 kernel halted system...
> original patch that was posted, which is a mirror of what the lz4 code
> looks like "upstream"?
>
> Why make this change?  Does it need to go into 4.0-final, or should I
> just revert the original patch?
>
> confused,
>
> greg k-h
>
OK, after further tests have modified the previous patch, please check and analyze:

[PATCH] lz4: fix system halted at boot kernel x86_64 compressed lz4

Decompression process ends with an error when loading 64bit lz4 kernel:

Decoding failed
 
    -- System halted

This condition is not needed for 64bit kernel ( from the last commit d5e7caf )

if( ... ||
    (op + COPYLENGTH) > oend)
    goto _output_error

macro LZ4_SECURE_COPY() tests op and does not copy any data
when op exceeds the value, decompression process is continued.

added by analogy to lz4_uncompress_unknownoutputsize(...)

Signed-off-by: Krzysztof Kolasa <kkolasa@winsoft.pl>
---
 lib/lz4/lz4_decompress.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
index f0f5c5c..8a742b1 100644
--- a/lib/lz4/lz4_decompress.c
+++ b/lib/lz4/lz4_decompress.c
@@ -139,8 +139,12 @@ 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 LZ4_ARCH64
+            if ((ref + COPYLENGTH) > oend)
+#else
             if ((ref + COPYLENGTH) > oend ||
                     (op + COPYLENGTH) > oend)
+#endif
                 goto _output_error;
             LZ4_SECURECOPY(ref, op, (oend - COPYLENGTH));
             while (op < cpy)
@@ -270,7 +274,13 @@ static int lz4_uncompress_unknownoutputsize(const char *source, char *dest,
         if (cpy > oend - COPYLENGTH) {
             if (cpy > oend)
                 goto _output_error; /* write outside of buf */
-
+#if LZ4_ARCH64
+            if ((ref + COPYLENGTH) > oend)
+#else
+            if ((ref + COPYLENGTH) > oend ||
+                    (op + COPYLENGTH) > oend)
+#endif
+                goto _output_error;
             LZ4_SECURECOPY(ref, op, (oend - COPYLENGTH));
             while (op < cpy)
                 *op++ = *ref++;
-- 
2.4.0.rc0.dirty



  reply	other threads:[~2015-04-03 11:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <55114A1D.7030508@winsoft.pl>
2015-03-25  0:44 ` lz4: fix system halted at boot kernel x86_64 compressed lz4 David Sterba
2015-03-25  7:04   ` Krzysztof Kolasa
2015-03-31 15:22     ` Greg KH
2015-04-03 11:33       ` Krzysztof Kolasa [this message]
2015-04-03 13:17         ` Greg KH
2015-04-03 13:58           ` Krzysztof Kolasa
2015-04-03 14:17             ` Alexander Kuleshov
2015-04-03 14:23               ` Greg KH
2015-04-03 14:30                 ` Krzysztof Kolasa
2015-04-03 14:44                   ` Greg KH
2015-04-03 15:12                     ` [PATCHv2] " Krzysztof Kolasa
2015-04-03 17:36                       ` Greg KH
2015-04-03 18:03                         ` Krzysztof Kolasa
2015-04-03 18:06                           ` Greg KH
2015-04-03 18:18                         ` Alexander Kuleshov
2015-04-03 19:01                           ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=551E7AA2.1050206@winsoft.pl \
    --to=kkolasa@winsoft.pl \
    --cc=dsterba@suse.cz \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tom.yeon@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox